The question a timeout cannot answer
When a request to a posting API times out, the client learns that no answer arrived. It does not learn whether the post exists. MDN describes the Request Timeout status in terms of the connection: the server would like to shut down this unused connection. That is a statement about a connection, not about a post.
Retrying blindly can produce a duplicate. Never retrying can lose a post. Both mistakes are public.
An explicit state for ‘I do not know’
The test suite records a post timeout after send as unconfirmed. A test docstring says 409 and 408 do not prove nothing was created, exactly like 5xx. So those answers are ambiguous, and ambiguous does not mean failed.
Failures before the post are different. A timeout while uploading the image is recorded as failed, not unconfirmed, and a test comment says ‘uploading creates nothing public: retryable’. A definitive 400 answer is recorded as failed, and the normal publish can retry.
What the unconfirmed state blocks
A second click on publish for an unconfirmed row answers already_attempted, and the mocked provider still has a single recorded post.
A row can also be left in the middle. A test docstring describes a process that died mid-POST, leaving a publishing row that is not retryable and not reconcilable. The same test says: After the sweep window it must become unconfirmed so the human recovery actions apply. The commit message says: LinkedIn: 408/409 ambiguous, stale publishing swept to unconfirmed, audited manual confirm/allow-retry.
A human is the way out
Two recovery actions exist, and both sit behind the human publish scope in the tests.
- confirm-published records the post URN, audits who confirmed, and makes no provider call. It also rejects references it cannot trust.
- allow-retry needs the row to be old enough and an exact confirmation phrase. A test comment states that allowing a retry does not post. The publish itself is a separate click.
The tests show that the recovery actions need the human publish scope.
The rule to take away
Idempotency is not a retry policy. It is a state machine with an explicit state for ‘I do not know’, and a human as the only way to force a retry.
If you run a posting integration, write down your ‘I do not know’ state before the first timeout hits.
