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.
Design application cancellation so a stopped HTTP wait cannot silently become a replacement paid action or an untracked running resource.
An application deadline controls how long its worker or user interface waits. It does not necessarily control a provider’s execution. Closing a browser tab, aborting fetch or terminating a process can stop observation while leaving an accepted action or running resource active.
Track a workflow deadline, per-request timeout and provider resource lifetime independently. Save the action identity before dispatch so another worker can inspect it after the original caller disappears. A canceled wait should leave a recoverable record with a last known phase, rather than erase the work item and invite a fresh create.
User cancellation can authorize stopping future workflow steps without establishing that every existing effect can be undone. For an allocated resource, identify the product’s supported cleanup operation and required permission. For a sent message or completed connected-app action, a generic cancel button cannot promise reversal.
Lupin’s budgets deliberately keep reads, known-result recovery and cleanup available. Use those operations to inspect and close resources under the existing authority. Do not assume a spending gate automatically terminates resources that were admitted earlier; the documented limits control new actions.
If the client aborts before it receives a result, the operation can still have reached the API or provider. Preserve the saved request and idempotency key and inspect the original operation’s recovery behavior. Do not label the work definitely unexecuted solely because the local timeout fired.
A durable record can distinguish prepared work from a dispatched request and a confirmed result. Those checkpoints help another worker decide which reads or recovery calls are appropriate. They remain claims about the recorded boundaries; a prepared checkpoint is not a guarantee that no earlier attempt with the same intent exists.
Run cleanup from a durable follow-up process when the original worker cannot finish it. Persist the resource identity, intended stop action, attempt time and observed terminal state. A finalizer in application memory is useful but insufficient if the process can crash or the runtime can end before it runs.
If cleanup itself times out, retain its original action identity and classify the outcome as unknown. A failed acknowledgment does not establish continued runtime, and a successful request does not always prove termination. Read the resource state or use provider evidence to close the lifecycle accurately.
Report a canceled workflow separately from resource closure. For example, the task can be stopped while cleanup is pending and an earlier paid attempt awaits reconciliation. This gives operators a reason to keep watching the resource without suggesting that the user’s task is still progressing normally.
At the next resume, start from the saved state rather than replaying the original instruction from scratch. Show unresolved external effects before accepting replacements. That approach preserves both the user’s deadline and the infrastructure’s need to finish or reconcile work already in flight.
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.
Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.