amal66 wants durable work queues without adding Redis
The unmerged proposal would make failure-prone background work survive restarts using the Postgres database most Mike deployments already have.
amal66's closed proposal separates work that needs to happen eventually from work a user should wait for in a browser tab. It adds retries, recovery after a service restart, protection against duplicate jobs, and cleanup of old records, while retaining existing behaviour if the queue is unavailable.
- Chat audit records: preserve multi-part conversation history even when a service restarts.
- Account deletion: remove access immediately, then keep retrying the underlying data and file cleanup until it completes.
- File cleanup: revisit failed storage deletions instead of silently leaving orphaned files behind.
- Data exports: let users request an export, check progress, and download it when ready rather than holding one web request open.
The work was tested but closed without merging, so this is a design worth inspecting rather than a capability to assume is live.
So what Legal teams that need dependable audit trails, defensible deletion, and reliable data exports should look closely at the approach if amal66 revives it.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?