Reconcile an unknown provider outcome before releasing its reservation

Freeze the affected action, not the evidence

A lost response creates an information problem: the provider may have acted even though your worker saw an exception. Stop automatic replacements for that logical action and retain its saved operation identity, request fingerprint and timestamps. A new retry key would describe another action and can defeat the protection that made the original attempt recoverable.

Lupin documents this boundary explicitly. Definitive rejection can release a usage reservation; a timeout or unknown outcome keeps it pending. Reads, known-result recovery and cleanup remain available under a spending limit. Use those paths to establish facts while the paid request stays gated.

Read the checkpoint as a claim with limits

The phone operation journal distinguishes initial intent, provider request, provider acceptance and completed local state. A provider_requested checkpoint proves that the local worker prepared to invoke the adapter. It does not prove acceptance. Conversely, a saved provider_succeeded outcome can contain enough projection data to rebuild a missing local resource without contacting the provider to create another one.

Treat the operation ID as a private correlation handle for support and diagnostics. It is not a receipt that a call was answered, a text delivered or a recurring charge canceled. Record exactly which checkpoint supplied each conclusion.

Reconcile both external and local state

Compare the authorized provider record with the durable journal and the local resource view. Match provider references, action, workspace and request time. A nearby action with similar content is weak evidence; another tenant or another attempt may have produced it. If the journal already contains a trusted known outcome, prefer its recovery path over guessing from a list.

Lupin phone recovery validates ownership and the existence of the project before applying its projection. It also protects later terminal call states and newer callback data. Recovery therefore means completing the original transaction locally, rather than overwriting everything with an old response.

Choose settlement, rejection or continued uncertainty

Provider acceptance permits the relevant usage to settle according to that product’s metering rules. An authoritative rejection can justify releasing reserved capacity. An absent search result, an unavailable provider dashboard or an expired client timer does not establish rejection. Keep the uncertainty visible until evidence resolves it.

When evidence conflicts, preserve the reservation and escalate with bounded metadata. Include the operation reference, product, approximate request time, saved phase and error code. Exclude credentials, recipient contact details and raw message content. The operator needs correlation, not a copy of the entire customer interaction.

Close the incident with an explicit invariant

Before resuming automation, verify that one intended action has at most one external execution, one settled usage identity and a coherent resource projection. Confirm that replaying the original identity reads or repairs its result rather than launching another paid action. Do not infer these properties merely because a later request returned success.

Finally, record whether the incident ended in acceptance, definitive rejection or manual reconciliation. Preserve unresolved cases as unresolved. That distinction allows a queue to resume safe work while preventing its recovery mechanism from silently manufacturing a second charge.

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 usage ledger and spending limits ↗Checked 2026-11-05
• Lupin error reference ↗Checked 2026-11-05

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.