[ericnewcomer]

Two problems that show up when a large backlog of old results is pruned.

Deleting a poll's results loaded every result id into memory

Poll.delete_poll_results evaluated the whole id queryset, only to count it, before deleting anything. On a flow with tens of millions of results that can exhaust the worker's memory, and the worker is killed before a single row goes. The ids are now streamed, and counted as they're deleted.

A continuation could be dropped, leaving its job stalled

A chunk enqueues its continuation before it releases the lease. If a worker picks the continuation up in between, its claim fails, and if the release lands before it checks why, it finds no lease and gives up, as if there was nothing to do. That message was the only thing driving the run, so the job stays running with nothing moving it until the next dispatch nudges it.

A failed claim on a running job that no longer has a lease now retries a few seconds later. Jobs that have ended or are paused are still skipped, as nothing is waiting on those messages and retrying one could start another run.

This doesn't change the wait when the lease is still live at that check, which is still until it expires.