The hosted Pi/Stripe runner reported failure. Stripe had accepted the test payment, the Durable Object had been deliberately reset, and the replacement instance had a different ID. The assertion that failed expected a marker written just before the reset to survive.
That marker was absent. The failed JSON is still in the evidence archive.
Separate the result from the assertion#
A later readback inspected the same operation and payment using the changed instance, the terminal transcript and the durable ledger. It did not replace the failed run with another payment. The full corrected hosted runner was not rerun with a third payment.
Those distinctions matter. A runner failing and an external action succeeding can both be true. A corrected assertion does not rewrite the historical runner result.
What I would carry forward#
Choose observations that can survive or be reconstructed across the failure boundary. Use more than a single marker as the recovery oracle. Keep the original output, then explain what later evidence changes—and what it does not.
For this experiment, the useful account is bounded: the unsafe tool was interrupted, the same payment was found, and the execution count remained one in the observed recovery. It is not a universal guarantee against duplicate business actions.
Read the full case study or inspect the original failed result.