Reconcile an unknown provider outcome before releasing its reservation
Use durable checkpoints and provider evidence to recover a paid action whose response was lost, while preserving the original operation identity.
Resolve a payload conflict without rewriting a paid operation
Investigate changed request data, serialization and operation identity when a durable action returns an idempotency conflict.
A conflict protects an earlier decision
An idempotency conflict means a saved identity is already bound to a request that differs from the current one. It is not a transient provider availability signal. Backoff cannot make two different actions become the same action, and replacing the key can create a second external effect while the first remains unresolved.
In the Lupin phone wrapper, the operation identity includes workspace, action and the supplied key. A fingerprint is calculated from the serialized input. An existing journal with a different input fingerprint returns idempotency_conflict. The useful question is therefore which request was intended, rather than how to force the newest payload through.
Recover the original request privately
Find the application’s immutable action record created before its first attempt. Compare resource, project, action arguments and any normalized defaults with the current request. Keep the comparison inside authorized diagnostics because request data can contain private messages or contact information. A public incident timeline needs field names and change categories, not complete payloads.
Check whether an editor, background enrichment job or retry library changed the action after dispatch. A regenerated timestamp, reordered input construction or new default may explain a mismatch. Client code should preserve the original accepted request representation instead of reconstructing it from mutable business objects on each attempt.
Separate correction from recovery
If the original operation may already have reached a provider, recover that operation before deciding whether a correction is necessary. A changed recipient, amount or resource target describes a new effect. Human intent to fix an error does not establish that the earlier action was canceled.
If the original request was durably rejected before execution, record that fact and the rejection’s scope. A new corrected action can then be considered through normal authorization and admission. Do not overwrite the old journal to make its history look as though the corrected payload had always been present.
Make serialization a deliberate client boundary
Normalize and validate the input once, persist it, then use that saved object for dispatch and retries. Avoid mixing user interface display fields with the API request. Store the logical action ID separately from per-attempt diagnostics so that a worker restart does not require guessing which key belongs to which payload.
The server’s current fingerprinting details are implementation evidence, not a promise that arbitrary JSON transformations are equivalent. Follow the operation’s actual contract. An application-level digest can help detect accidental local changes, but it does not override the provider journal or authorize a different action under the same identity.
Prevent the next mismatch at the queue boundary
Use states such as prepared, dispatched and resolved. After dispatch, changes should create a reviewed successor action rather than mutate the original. Link that successor to the original incident so an operator can understand why two intended actions exist and which external effects each may have produced.
Include a local regression case where the first attempt loses its response and the retry uses edited data. The expected behavior is a visible conflict with no second provider call. Also check that identical saved input can recover the existing result. This tests the failure that matters without purchasing a resource or sending a message.
Sources & verification
Reviewed against the checked-in Lupin implementation and official reference documentation on 2026-11-05. Operational examples are illustrative; no live paid action, provider mutation or external message was executed.
- Lupin API conventions Checked 2026-11-05
- Lupin error reference Checked 2026-11-05
- Lupin usage ledger and spending limits Checked 2026-11-05
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.