ENGINEERING NOTE / SEPTEMBER 7, 2026

61 tests passed. A late invoice still restored access.

The first Billing Replay release passed its independent test suite. A two-event sequence then showed that its corrected teaching adapter could still reopen a canceled account.

Written with Codex from executed local tests. This is a defect in our synthetic example, not a claim about Stripe or a customer’s production app.

The branch the suite missed

The demo declared a simple policy: a newer cancellation should survive an older status update. A test already covered an old activation arriving after cancellation. That test passed.

The invoice branch was different. It added credits, set access = true, updated the logical timestamp, and returned before reaching the stale-status check. The rule was present in the code, but this event type never used it.

// Original teaching adapter: invoice.paid branch
state.credits += credits;
state.access = true;
state.statusCreated = Math.max(event.created, state.statusCreated);
return;

Reading that early return changed the next test. Instead of sending another activation, we canceled a fresh test account at logical time 30 and delivered a paid invoice from logical time 20.

The original fixed adapter returned this result:

{
  "expected": { "access": false, "credits": 10 },
  "actual":   { "access": true,  "credits": 10 }
}

The balance was correct. The access decision was not. Counting only credits would have missed the defect too.

A small fix needs a test that can disagree

The correction applies the demo’s timestamp rule inside the invoice branch. A late invoice still adds its credits once, but it cannot restore access after the newer cancellation.

state.credits += credits;
if (mode !== 'fixed' || event.created >= state.statusCreated) {
  state.access = true;
}

An independently written regression now cancels the account, delivers an older invoice, repeats that invoice, and finally delivers a newer invoice. It checks that access stays blocked for the old event, credits are not added twice, and the newer event can grant access. That last step prevents a “fix” that simply blocks all future invoices.

The same regression checks that the deliberately vulnerable adapter fails on the old-invoice step. This proves the test can distinguish the behavior being fixed.

The release now passes 62 independent tests. Its corrected demo passes eight scenarios, while the deliberately vulnerable demo fails six. Those counts describe the executed checks; they do not establish that every possible sequence is correct.

Keep this model separate from Stripe’s event ordering

These fixtures use logical timestamps to make one policy easy to inspect. Real Stripe created values have second-level precision and can tie. Stripe explicitly says not to use them as an event-ordering or deduplication mechanism. A production integration needs its own reconciliation policy and authoritative state. Stripe’s event ordering guidance.

This distinction matters because the easiest code to copy is often the code with the fewest moving parts. The teaching adapter is useful for learning how the runner reports an incorrect decision. It is not a production billing handler.

What changed in how we test

The useful unit of coverage here was a business effect reached through an event branch. Activation and paid invoices could both grant access. Testing one route into that effect did not cover the other.

When a rule says “an old event must not reopen access,” enumerate the event types that can reopen it. Keep the expected access and balance explicit. Then exercise the real application path and read its actual state; a separate reducer that agrees with itself is weak evidence.