Verified #015 established a real HTTP ambiguity: the remote effect can commit while the client receives RemoteDisconnected. #016 asks what happens next if the remote service itself dies and comes back before recovery.
The experiment separates effect memory from dedupe memory.
The remote effect ledger is always SQLite on a persistent Docker volume. In the unsafe path only the idempotency map is process memory. That lets the first effect survive while the service forgets that it already handled the key.
Effect ledgerPersistent SQLite volume · survives container replacement.
Dedupe stateVolatile memory in unsafe mode; persistent SQLite record in safe mode.
Unsafe · the effect survived, the safety memory did not.
The first container reported boot id 7fa5e591…. The remote service committed one effect, dropped the HTTP response, and the client observed ACK_UNKNOWN.
After restart the durable effect ledger still reported COMMITTED / effect_count=1, but the volatile dedupe map was empty. The worker correctly reused the same key — and the new process applied it again.
Final unsafe state: 2 POST requests, 2 remote effects, CONFLICT.
Safe · durable idempotency state survives the restart.
The durable mode persisted both the effect and its idempotency mapping. The first boot 36d472f4… committed the effect and lost the response. After container replacement the new boot 696deb30… still observed one effect and one durable idempotency record.
The real second HTTP delivery therefore remained safe across process death: 2 delivery attempts, 1 committed remote effect.
Recovery alternative · reconcile the effect ledger.
A third path intentionally lost volatile dedupe memory again. After restart, recovery queried authoritative remote status first. It found COMMITTED / effect_count=1 and made no second POST.
What #016 adds to TTP.
STABLE KEY + VOLATILE DEDUPE STATE ≠ IDEMPOTENT DELIVERYIdentity requires memory with adequate durability.
REMOTE EFFECT DURABILITY ≠ IDEMPOTENCY-MEMORY DURABILITYThese are separate properties.
DEDUPE STATE MUST SURVIVE THE FAILURE WINDOW IT PROTECTSRestart is part of the protocol threat model.
SERVICE RESTART IS A TRUST-MEMORY TRANSITIONRestart evidence belongs in the trajectory.
Evidence.
GitHub Actions run 31466444029 completed successfully. Artifact resonance-idempotency-state-durability-v1.0 has ID 9091692210 and digest sha256:968fdc68906cfdb2603e3b130a0f0c487d1b406f2eb9d73d6f6f6224231cdd13.
Execution used PostgreSQL 17.6, python:3.12-slim for the HTTP service, and a persistent Docker named volume with a SQLite remote ledger.
Interpretation boundary.
This is a local restart-durability benchmark, not a multi-region durability or exactly-once certification. It does not model total volume loss, replicated caches, disk corruption, consensus or production payment-provider semantics. It is also not yet a CML integration; it is a protocol result about durable execution memory that can inform one.
Inspect / reproduce
Verdict: the durability of safety memory must be at least as strong as the failure window it is expected to survive.
RESONANCE Verified #016
effect durability → memory durability → restart recovery → proof.
Read TTP v1.0