ON CONFLICT DO NOTHING and retried jobs

Move the timeout one step earlier, before the external reply arrives. The client stops waiting. The worker doesn't. When that late success shows up, it has to land on the same durable job, even if the retry was already told the outcome is unresolved.

One invariant first. Each identifier has exactly one accepted payload identity, and a conflict says nothing about whether the new request matches it or whether the job finished. Read the stored row and compare identities before you pick a response. For PostgreSQL 18 under Read Committed, a plain SELECT sees a snapshot taken when that command starts, so be explicit about which later query reads the state you report.

That seems manageable without adding much. Tag the late result with the original job identifier, and let one small status lookup report the job as running, unresolved or completed. Then the retry and the late success end up talking about the same job.

The worst spot is narrower than a timeout. The external service has accepted the action, and the worker crashes before writing the result. The supervisor restarts it. What state can it rebuild? The stored job has no result, and the restart doesn't say whether submitting again is safe.

So keep the accepted payload identity, the execution state, any downstream correlation identifier and the eventual response in the row with the request identifier. A replacement worker decides its next step from that row alone.

Even then the remote success can land before the write. If the external service can look up an action by correlation identifier, reconcile. If it documents idempotency keys, give it the accepted job's key. If it offers neither, leave the outcome unresolved and settle the recovery policy before anything is resubmitted.

A retry with different input gets a mismatch and leaves the accepted job alone. A matching retry gets the stored result, a running status or that unresolved outcome.