The application may lose its connection after a provider accepts a message. Immediately repeating the send can create a second customer action. Design the unknown state before attaching retries to the transport.
Keep your action separate from the request
Give the intended business action an internal identifier before dispatch. Persist the destination, permitted sender and purpose in a form your system can inspect. Associate provider identifiers when they become available, without treating the presence of an HTTP response as the only record of the action.
A documented immediate rejection can be handled differently from a timeout with no conclusive result. Use the provider’s actual error definitions. Do not invent an idempotency header or assume a general messaging pattern is implemented by every service.
Reconcile before repeating
Where the provider documents a lookup, query it using a stable identifier. messages.dev’s introduction, for example, points to an outbox surface and a sent event for tracking. Inspect the current endpoint behavior and account scope before relying on that mechanism.
If no reliable lookup is available, retain the unknown result and define an operator path. A message can matter enough that an explicit unresolved state is preferable to a silent duplicate. Retry policies should distinguish transport uncertainty, rate responses and permanent permission failures.
Connect the later evidence
A subsequent event can resolve the unknown state. Store it with the original action, preserve event timing and keep delivery separate from a customer’s actual reply. Handle a late arrival after an operator has already acted, so the old job cannot restart the conversation.
The following is conceptual pseudocode, not an SDK example or a guarantee that a provider implements these operations. The point is the state transition your application must decide, including the evidence that permits another attempt.
ACTION created
→ dispatch under documented permissions
→ accepted: retain provider identifier
→ rejected: classify the documented error
→ unknown: reconcile or request operator review
Later verified events enrich the original action.
Another send requires an explicit retry decision.