Retry needs idempotent effects

A consumer can run an event again after failure. Processing guarantees inside one store do not cover every external side effect29.

In an idempotent system, the outcome of processing a message once is identical to the outcome of processing it multiple times.

Source: Q1033; B533, B633.

Failure it prevents

A response disappears after a remote write succeeds, and retry repeats the write.

Our Effect 4.0.0 reading

Workflow identity and Activity.idempotencyKey name work. Receiver-side keys or transactional dedupe must enforce the repeated effect’s semantics.

Source: packages/effect/src/workflow/Workflow.ts, packages/effect/src/workflow/Activity.ts, packages/effect/src/workflow/DurableQueue.ts.

How to check

Lose the response after remote success. Retry the same identity and inspect the authoritative result. This check is our proposal. The books do not prescribe it.

Continue with Checkpoints follow the promised commit10, Cleanup can be an idempotent postcondition10.

Connect this to the existing rat-stack guidance23.

Use the durability skill for the full review. Return to the durability index34.

Sources

  1. Bellemare, Adam. Building Event-Driven Microservices: Leveraging Organizational Data at Scale. O’Reilly, 2020.. O’Reilly. Chapter 3 Communication and Data Contracts; Chapter 6 Deterministic Stream Processing; Chapter 7 Stateful Streaming; Chapter 9 Microservices Using Function-as-a-Service; Chapter 14 Supportive Tooling. Accessed 2026-10-23.
  2. Reis, Joe; Housley, Matt. Fundamentals of Data Engineering. O’Reilly.. O’Reilly. Part II, Chapter 5: Message Queues; DataOps considerations; Incident Response. Accessed 2026-10-23.
  3. Effect contributors. Effect 4.0.0. workflow/Workflow.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.
  4. Effect contributors. Effect 4.0.0. workflow/Activity.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.
  5. Effect contributors. Effect 4.0.0. workflow/DurableQueue.ts. Effect-TS. Pinned source for our Effect mapping, not a claim from the book. Accessed 2026-10-23.

Last changed 2026-10-23 in 58dc623. Source on GitHub. Change log.

Linked from

  1. add-a-store. Add persistence through a service named for an application job, with validation, vendor Layers, migrations, bounded reads, and shared backend tests.

    Check replay and interrupted execution when the new operation promises idempotency or atomicity.¶

  2. Agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.

    Retry needs idempotent effects — Repeating an operation must preserve its intended observable result.

  3. Change log. What changed in the files served here, newest first.

    Retry needs idempotent effects — new page: docs(lore): land the durability wiki pages and bibliography

  4. Checkpoints follow the promised commit. Persist state and progress together when one store can transact both.

    Continue with Retry needs idempotent effects, Dead letters need a return path.¶

  5. Cleanup can be an idempotent postcondition. Already-absent state can be success when absence is the operation’s intended result.

    Continue with Retry needs idempotent effects, Failures keep their meaning.¶

  6. Dead letters need a return path. Exhausted work needs durable evidence, an owner, and deliberate redrive.

    Continue with Retry needs idempotent effects, Golden signals expose overload.¶

  7. durability. Keep a rat-stack app standing when a provider, pool, or dependency slows down or a worker dies. Use at any I/O boundary, connection pool, provider call, shared waiter, fan-out, flag, gate, or work that can outlive a request, or when asked "what happens when this is slow", "add a timeout", "make this durable", or "what survives a crash".

    The receiver or authoritative store must enforce deduplication; drovr does it by submission id.¶

  8. Durability starts with a recovery record. A reading order for storage, replay, worker ownership, overload, and recovery tests.

    Retry needs idempotent effects: Repeating an operation must preserve its intended observable result.¶

  9. Full agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
  10. HTTP success needs a status check and a decoder. Supply the client, check the response status, decode accepted data, and name failures at the adapter boundary.

    Identify the operation’s replay or idempotency guarantee: whether repeating it can create a second change.¶

  11. Rat Stack lore | rat-stack. Short, source-grounded notes on the ideas and decisions behind rat-stack.

    Retry needs idempotent effects — Repeating an operation must preserve its intended observable result.

  12. Request lifetime is not durability. Worker waitUntil has a shared post-response allowance; required work needs a durable marker and redrive.

    Continue with Timeouts bound waiting, Retry needs idempotent effects.¶

  13. Source change history (log.md). The generated change log as Markdown.

    Retry needs idempotent effects — new page: docs(lore): land the durability wiki pages and bibliography

  14. Timeouts bound waiting. A local timeout stops waiting; it does not prove the remote action never happened.

    Continue with Retry load needs a budget, Retry needs idempotent effects.¶