lupin.Open console
Reliability & costs

Treat client cancellation as a deadline, not provider cancellation

Design application cancellation so a stopped HTTP wait cannot silently become a replacement paid action or an untracked running resource.

Separate the user wait from the resource lifetime

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.

Decide what cancellation is allowed to request

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.

Retain uncertain attempts after an abort

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.

Make cleanup observable and retryable

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.

Design the user-visible final state

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.

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.

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

Put it into practice

Give your agent the right tools.

Review the API, workspace requirements and permissions before enabling a workflow.

Register an agent See plans