Long-running work needs a product surface

BullMQ is excellent at delayed work, retries, schedules, and worker coordination. It is not automatically a customer-facing history of what was accepted, which stage is running, whether a retry is safe, or what an operator did to recover a failure.

That product truth belongs in PostgreSQL. A committed process record lets the request return a queued state immediately, even when no worker is available yet. The queue can then execute from a durable outbox handoff.

Queued, running, waiting, succeeded, failed, and canceled should be explicit states with timestamps and low-volume milestones. A spinner inferred from an open request cannot explain a retry tomorrow or an operator recovery next week.

Milestones should describe meaningful stages without copying provider payloads into the database. The interface can then answer what is happening while logs and traces continue to serve diagnosis.

• Accept work and commit the queued snapshot before returning.
• Publish the queue command through an idempotent outbox relay.
• Store bounded milestones and a clear terminal outcome.
• Deduplicate terminal notifications by process and recipient.

A focused test can prove transitions, idempotency, and publication logic. Disposable database checks can prove constraints and query behavior. Authenticated preview evidence is still required to show that PostgreSQL, the outbox relay, BullMQ, Electric, and the browser converge in the deployed environment.

Keeping those lanes separate produces more honest releases. It also makes incidents faster to classify because the team knows whether it is looking at application behavior, generated output, environment setup, provider health, or deployment drift.