# Durable actions and the ambiguous timeout Canonical: https://semiaifoundry.com/learn/atlas/durable-actions-idempotency/ Revision: 2026-10-07 Rights: https://semiaifoundry.com/ai-atlas/licenses.html From request to durable action · Atlas v1.3.0 # Durable actions and the ambiguous timeout Persist intent, execute with idempotency key, store receipt and recover without duplicate business effects. [Explore in Atlas](https://semiaifoundry.com/ai-atlas/#durable-actions-idempotency)Logical state, task evidence and declared units; no physical assembly scale Learning objectiveExplain the caller’s uncertainty and prove that recovery preserves one logical effect after a commit-before-response failure. ## The mechanism A write can commit even when its response never reaches the caller. Retrying blindly then risks creating a second external effect; refusing every retry can leave a valid task unfinished. An idempotency key names one logical action, while a payload fingerprint records exactly which action that key refers to. The service stores an effect and its receipt together at its own boundary. A matching retry returns the original receipt; a changed payload under that key must not silently reuse or replace it. A workflow journal records intent before service and observations afterward. Those records can lag the external effect. The incident experience deliberately separates local journal and environment storage so an interrupted result write leaves a real reservation to recover. This is different from restoring neural weights or replaying lost arithmetic: an external reservation is already part of the world. 1. Persist the approved action intent before starting the service that can mutate inventory. 2. The service validates the key and payload, commits one reservation and stores its original receipt. 3. If the response is lost, the caller records uncertainty rather than success or proof that nothing happened. 4. Receipt lookup or an identical idempotent retry recovers the outcome; conflicting arguments fail without another effect. ## Science and assumptions ### Durable actions and the ambiguous timeout · explicit relationship $$ F_{k,p}\!\left(F_{k,p}(W)\right)=F_{k,p}(W) $$ Applying the same keyed action with the same payload to world state twice has the same effect as applying it once. Symbols and units W External environment, including the receipt ledger state object k Stable logical action key identifier p Exact action payload bound to the key data object Fₖ,ₚ Service transition with an atomic keyed receipt state transition FAN-7 begins with four FILTER-A units. The reservation for quantity two commits, leaving two units and receipt K. The response is lost. A repeat request carrying K and the same payload returns the original reservation: stock stays at two. A request carrying K but quantity one conflicts with its stored fingerprint and changes nothing. If result journaling itself fails, reload retains the committed environment and the pending intent; recovery reconciles that exact receipt before continuing to the work order. Assumptions The key and payload are unchanged, receipt retention covers the retry, and the service atomically commits the effect and receipt. This is an effect guarantee under those assumptions, not an exactly-once network-delivery claim. ## Engineering example FAN-7 begins with four FILTER-A units. The reservation for quantity two commits, leaving two units and receipt K. The response is lost. A repeat request carrying K and the same payload returns the original reservation: stock stays at two. A request carrying K but quantity one conflicts with its stored fingerprint and changes nothing. If result journaling itself fails, reload retains the committed environment and the pending intent; recovery reconciles that exact receipt before continuing to the work order. ## Distinctions and tradeoffs A timeout is neither proof of nonexecution nor permission to issue a new logical action. Idempotency requires durable service-side identity and payload matching; a client-side retry counter alone cannot supply that guarantee. Agents and workflows can be restarted, but durable side effects need an explicit recovery contract. ## Specifications and interfaces Mechanism boundary Did a timed-out write happen? The key and payload are unchanged, receipt retention covers the retry, and the service atomically commits the effect and receipt. This is an effect guarantee under those assumptions, not an exactly-once network-delivery claim. Evidence type Authored worked example The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. ### Interfaces Declared input and state Input Persist the approved action intent before starting the service that can mutate inventory. Checked outcome Output Explain the caller’s uncertainty and prove that recovery preserves one logical effect after a commit-before-response failure. ## Check your understanding ### After the reservation committed but its reply was lost, what should the same-key retry do? 1. Reserve two more units 2. Return the original receipt without changing stock 3. Erase the first reservation Answer and reasoning Return the original receipt without changing stock The service recognizes the same logical action and returns its already committed outcome. ## Evidence and scope The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. The quantities and fixtures are authored. Source scope is recorded in the automation learning review manifest; no source benchmark or private system behavior is claimed. The key and payload are unchanged, receipt retention covers the retry, and the service atomically commits the effect and receipt. This is an effect guarantee under those assumptions, not an exactly-once network-delivery claim. The durable incident experience executes typed fixture tools, authority checks, exact review, receipts and independent final-state checks. Its policies are authored code and its storage boundary is local; it is not a real model or production workflow platform. ## Sources - [Temporal Activities](https://docs.temporal.io/activities) - [Temporal Workflow Execution](https://docs.temporal.io/workflow-execution) - [LangGraph persistence](https://docs.langchain.com/oss/python/langgraph/persistence) [Published lesson data](https://semiaifoundry.com/ai-atlas/lesson-data/durable-actions-idempotency-0913e642cc5c0015.json) · [Atlas releases and licensing](https://semiaifoundry.com/ai-atlas/licenses.html) ## Continue exploring ### Foundations - [Events, queues and backpressure](https://semiaifoundry.com/learn/atlas/event-queues-delivery/) ### Related lessons - [Tools, memory & agent loop](https://semiaifoundry.com/learn/atlas/tool-loop/) - [Evaluation & the AGI frontier](https://semiaifoundry.com/learn/atlas/evaluation/)