What should a duplicate job request return?

Put the timeout before the external reply. The client may stop waiting while the worker continues. A late success needs to update the same durable job, even if the retry has already received an unresolved status.

I would start with one invariant. Each identifier has one accepted payload identity. DO NOTHING does not establish that a conflicting request has the same input.

Retrieve the durable record and compare that identity before choosing the response. For PostgreSQL 18 Read Committed, a plain SELECT uses a command-start snapshot, so name the later query that retrieves the state you intend to report. A conflict alone is insufficient evidence for either a matching payload or a completed job.

Give the late result the original job identifier. Then expose that job's running, unresolved or completed state through one small status lookup.

Consider the failure between the external service accepting the action and the worker recording its result. A supervisor may restart the worker, but the stored job can still lack that result. Restarting does not answer whether submitting again is safe.

I would persist the accepted payload identity, execution state, any downstream correlation identifier, and the eventual response alongside the request identifier. A replacement worker should reconstruct its next decision from that record.

Those fields still leave a gap if the remote action succeeded before the result was recorded. If the external service supports looking up an action by the correlation identifier, reconciliation can be the next step. If it supports an idempotency key under an explicit contract, the same accepted job can use that facility. Otherwise, keep the outcome unresolved and define a recovery policy before another submission.

A retry with different input should receive a mismatch response without replacing the accepted job. A matching retry can receive the stored result, a running status, or that unresolved outcome.