Replay needs stable inputs

Deterministic processing should agree between live consumption and catch-up. Event ordering and late-arrival rules belong to the domain.

The overarching goal of deterministic processing is that a microservice should produce the same output whether it is processing in real time or catching up to the present time.

Source: Q1133; B533.

Failure it prevents

Reprocessing the same history changes decisions because time, ordering, or an external answer changed.

Our Effect 4.0.0 reading

Activity can record an effect29 result under an engine. Stream does not choose event-time ordering, lateness policy, or protect a rebuild from live writes.

Source: packages/effect/src/workflow/Activity.ts, packages/effect/src/Stream.ts.

How to check

Replay captured input into a clean target with controlled decisions. Compare output and apply the declared late-event policy. This check is our proposal. The books do not prescribe it.

Continue with Old events must still decode9, Pure cores reduce timeline coupling9.

Connect this to the existing rat-stack guidance25.

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. 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.
  3. Effect contributors. Effect 4.0.0. Stream.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. Agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.

    Replay needs stable inputs — Historical processing must not silently depend on today’s clock or external decisions.

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

    Replay needs stable inputs — new page: docs(lore): land the durability wiki pages and bibliography

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

    Replay needs stable inputs: Historical processing must not silently depend on today’s clock or external decisions.¶

  4. Full agent guide. An Effect stack so pure (aspirational) Kit Langton will blush.
  5. Old events must still decode. Retained data needs compatibility rules before recovery depends on it.

    Continue with Shared schemas need a transition period, Replay needs stable inputs.¶

  6. Pure cores reduce timeline coupling. Move deterministic rules out of time-dependent actions and shared mutable state.

    Continue with Replay needs stable inputs, Recovery needs model tests.¶

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

    Replay needs stable inputs — Historical processing must not silently depend on today’s clock or external decisions.

  8. Restart must reconstruct known state. Execution recovery and state recovery need separate contracts.

    Continue with Replay needs stable inputs, Durable timers need recovery.¶

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

    Replay needs stable inputs — new page: docs(lore): land the durability wiki pages and bibliography