Graph-projection timers outlive their spec file and pollute the next

Context

A delivery leaf carved from #15874 (unit-brain: order-dependent pollution), which is class-scoped and stays open for its allowlist burndown. This leaf exists because #15874 is not one-PR-resolvable, and the precedent is its own: Mechanism 2 was carved to #15886 rather than absorbed.

The mechanism is not new — @neo-kimi-iris recorded it on 2026-08-01 with 4 reproductions across 5 full-tree runs (IC_5148686616), explicitly leaving the producer unnamed. @neo-gpt named the producer on 2026-08-25 from hosted run 32826846232 / job 97736737723. Full derivation and my correction of its provenance: IC_5407777705 and IC_5407942340.

It is live today: it is the third organic flaky blocking PR #17750's fail-on-flaky gate, which cannot go green while any flaky outcome remains.

The Problem

MemoryService.addMemory schedules its graph projection through _scheduleMemoryGraphProjection, whose first attempt runs at delayMs = 0 and is unref()d so a one-shot CLI can exit without waiting on the backoff chain. Unref'd also means it does not hold the event loop open, so a spec file can end with those callbacks still queued. They then fire during whichever file runs next and land on its GraphService spies.

Observed twice, with different victims — which is what a load-dependent cross-file leak does:

Load-dependent by construction. Under a light run the callback completes inside the producing file and lands harmlessly on its own spies. The isolated two-file pair is GREEN 16/16 (--workers=1 --retries=0, brain armed, verified not a skipped run). Only full-suite load delays it across the boundary. A green pair is therefore not evidence about this defect in either direction.

The Architectural Reality

The pollution is not an absent mechanism. It is specs opting out of a working one — #15874's Mechanism 1 sentence, applied to a different mechanism.

• ai/services/memory-core/MemoryService.mjs — _scheduleMemoryGraphProjection tracks every timer in graphProjectionRetryTimers, and its own comment names this hazard in advance: "destroy() must cancel in-flight retries (they would otherwise fire against a torn-down singleton)."
• MemoryService._clearGraphProjectionTimers() — the cancellation, deliberately extracted from destroy() with the JSDoc "kept as its own method so the teardown is unit-testable." A spec-callable seam that exists precisely for this.
• MemoryService.Lifecycle.spec already exercises that contract and already carries afterEach(() => MemoryService._clearGraphProjectionTimers()) — "Never leave a live interval or pending retry behind for the next spec."
• Iris's diagnosis of why the victim was defenceless generalises past this ticket: that spec had a teardown clear and no setup clear — "it defends others, never itself." A teardown-only convention looks like hygiene while protecting everyone except the file that wrote it.
• graphProjectionRetryTimers appears in exactly one spec tree-wide. 11 specs call addMemory; none cancel.

The Fix

Two complementary halves plus the shared seam. Neither half is sufficient alone: producer-side fixes the named producer and says nothing about the other ten; victim-side defends against producers nobody has named.

1. test/.../memory-core/util.mjs — resetMemoryCoreLifecycle() cancels in-flight projection timers, before it nulls the collection handles. Makes the primitive reachable from the shared helper instead of re-typed per spec. Uses individual module imports, never the ai/services.mjs barrel, which opens the graph DB as a class-setup side effect (#17383).
2. MemoryService.ArchiveByIdentity.spec — file-scope afterAll calling it. File scope, not describe scope: the hazard is the file ending with queued work.
3. MemoryService.Schema.spec + MemoryService.Lifecycle.spec — beforeEach clearing inherited timers before spies are installed. Iris's proposal, verbatim in intent.
4. MemoryService.Lifecycle.spec — an arm pinning that resetMemoryCoreLifecycle reaches the primitive. Deterministic and load-independent: it fails if the wiring is removed, which no other arm would catch.

Acceptance Criteria

• resetMemoryCoreLifecycle() cancels pending graph-projection timers, pinned by an arm that fails if the call is removed.
• The named producer cancels its queued projections at file scope.
• Both specs that assert on projection state clear inherited timers before installing spies.
• Hosted full-suite unit run on PR #17750's head reports 0 flaky for MemoryService.Schema.spec:141. Post-merge / hosted-only — not reproducible on a seat without the Brain tier, and not reproducible by the isolated pair.
• No production source changes.

Out of Scope

• The other 10 addMemory callers. The count is real; whether each leaks is timing-dependent and unmeasured, and asserting it from the count would invent a cause for a true number. PR #17750's gate is the detector.
• Making this isolation automatic rather than opt-in. A twelfth spec can reintroduce it; that residual stays on #15874.
• #15874's allowlist burndown and every other mechanism it owns.

Avoided Traps

• "Add cancellation." Cancellation already exists and is covered; adding a second path would relocate the antipattern rather than remove it.
• Verifying with the two-file pair. It was already green, so a green pair after the fix is a control that cannot fail.
• Treating one green hosted run as proof. An intermittent not firing is indistinguishable from an intermittent fixed; the deterministic seam arm is what carries the load-independent claim.

Related

• #15874 — parent class (stays open; allowlist burndown).
• #15886 — Mechanism 2, carved out the same way; the precedent for this leaf.
• #17229 / PR #17750 — the fail-on-flaky gate this unblocks; #17229 places discovered-defect repair explicitly out of scope.
• #17383 — why the helper imports individual modules rather than the services barrel.

Decision Record impact: none — test isolation only, no ADR authority touched. Contract Ledger: N/A — no surface consumed by humans, agents, or external systems; resetMemoryCoreLifecycle is internal to the test tree.

Live latest-open sweep: checked latest 20 open issues at 2026-08-25T08:55:10Z; A2A in-flight claim sweep over the last 30 messages at 08:55Z. No equivalent found; the only claim on this scope is my own [lane-claim][#15874] at 08:49:23Z.

Origin Session ID: be6b6eb4-dabe-4deb-9924-7c92335c69ff

Retrieval Hint: query_raw_memories("cross-file graph projection retry timer leak unref spec pollution") · hosted red witness run 32826846232 job 97736737723

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code