fix(memory): reflection must not reject after a store closes

[plombeer31]

What

ReflectionRunner.reflect() is documented fire-safe — see the invariants block in src/memory/reflection/reflection-runner.ts ("The caller can void runner.reflect(input) safely") — and AgentLoop.runTurn relies on exactly that with a bare void. Two decorators wrap that runner, and both hydrate candidate ids out of SQLite-backed stores after awaiting the inner runner, outside every try:

• src/memory/voting/vote-aware-reflection.ts — hydrateCandidates() reads memoryStore, lessonStore, profileStore, procedureStore
• src/memory/links/link-aware-reflection.ts — the notesStore.get(id) loop

A throw from any of those rejects reflect(), and with nothing attached to the promise the process reports an unhandled rejection, which src/error-reporting/error-reporter.ts:91 forwards to the crash reporter.

Why it fires in the wild

Runtime shutdown() (src/runtime/bootstrap.ts:2214) does this, in order:

reflectionRunner?.abortPending();   // settles the INNER reflection
… await telegram.stop(); await mcpManager.shutdown(); await browserBackend.shutdown();
profileStore.close(); lessonStore.close(); procedureStore.close(); notesStore.close();

The abort settles the inner runner, so the decorator's continuation resumes and hydrates from stores the shutdown has since closed. better-sqlite3 answers a statement on a closed handle with a real TypeError:

TypeError: The database connection is not open

The synchronous closes win the race: the reflection chain needs more microtask hops to unwind (abort listener → Promise.race → await llmComplete resume → runOne catch → finish → settle → decorator resume) than shutdown() has awaits. Reproduced end-to-end in a bootstrap-shaped composition (real stores, real createReflectionRunner, decorators layered the way bootstrap.ts layers them), both with resolved-promise teardown and with ~10 ms of real async teardown.

The shutdown comment already names the hazard — "Cancel any in-flight reflection before tearing down the profile store — otherwise a late-arriving completion could try to write into a closed SQLite connection" — but abortPending() only signals; nothing is awaited, and it only reaches the inner runner. The decorators were added after that comment and read stores past the abort point. (The stale claim at agent-loop.ts:507 that shutdown "drains" in-flight reflection is corrected in this PR.)

Second, separate hazard: profileFactsProvider

profileFactsProvider is wired as a raw () => profileStore.list() (bootstrap.ts:2121) and evaluated synchronously at two points in runTurn:

• agent-loop.ts:654, inside the step loop's own try. A throw there lands in the step catch, is classified by classify-failure.ts (a TypeError matches neither isAbortError — "The database connection is not open" contains no aborted — nor isNetworkError, so it defaults to tool), emits loop_failed, and fails the turn the user is waiting on.
• agent-loop.ts:1150, purely to build the reflection allowlist.

Fix

• Both decorators guard their hydration and warn on the caught failure; bootstrap.ts passes the logger already in scope at both construction sites. Guarded wholesale rather than per-id: the vote-runner scores a set, and a silently truncated allowlist would let it deprecate whichever entries happened to hydrate before the failure.
• profileFactsProvider guarded at both call sites, each with its own warning. The step-loop one renders that step without profile facts.
• The void reflect(...) call site carries a trailing .catch that warns, as the outermost guarantee.

Every new guard reports. Swallowing silently would trade a visible crash for an invisible loss of curation, and it is not what the sibling paths do (agent-loop.ts:1327 logs memory context provider failed).

No behaviour change on the healthy path: profileFacts is spread as ...(profileFacts !== undefined ? { profileFacts } : {}) on both sides, so a healthy provider is byte-identical and a throwing one produces exactly the "no provider wired" shape. Control tests assert the full allowlist still reaches the vote runner and the link generator.

Sentry

Four clusters carry this signature. Only shortIds, counts and code paths quoted.

Cluster	Events / users	Window	Signature
CLI-B6	16 / 2	2026-08-28 → 2026-09-03, releases 0.5.4 (11) + 0.4.2 (5)	TypeError at store.get ← hydrateCandidates ← Object.reflect ← processTicksAndRejections
CLI-6G	16 / 2	win32, 0.4.1 / 0.3.2 / 0.2.1 / 0.1.72	same, via getById
CLI-6H	14 / 3	linux + darwin, 0.3.5 / 0.4.1 / …	same, via .get
CLI-34	9 / 1	category=tool	TypeError at profileStore.list ← Object.profileFactsProvider ← runTurnInner — the second hazard above

CLI-B6 is still firing on 0.5.4, which is why this is worth a fix rather than a note. CLI-34 is single-user and on an old release; it is cited as corroboration for a code path that is still live on main, not as the justification.

Test evidence

src/memory/reflection-decorator-fire-safety.test.ts (11 cases) builds real MemoryStore / ProfileStore / LessonStore / ProcedureStore on a temp SQLite file and closes them from inside the inner runner, reproducing the shutdown interleaving rather than mocking a throw. It pins the premise (a post-close read really is a TypeError), the healthy path, the wholesale-vs-per-id decision, that the guards are not narrowed to TypeError, and the warnings themselves.

src/agent/agent-loop-reflection-fire-safety.test.ts (4 cases) installs an unhandledRejection listener around a real runTurn and asserts none fires, pins the turn outcome (reason / status, not just the session id, which is identical on the failing path), and asserts both profile-facts guards report.

Non-vacuity, by reverting each src file onto the branch:

• revert both decorators → 8 of 11 decorator cases fail (the 3 survivors are the premise pin and the two "stores open" controls)
• revert agent-loop.ts → 3 of 4 loop cases fail, with the unhandled rejection actually observed on main (expected [ …(1) ] to deeply equal []) and the turn outcome as expected 'failed' to be 'reply'

Mutation battery — 9 of 9 functional mutations killed:

Mutation	Result
vote hydration made per-id (continue past a bad store)	killed (4 tests)
link-aware guard falls through with a partial allowlist	killed
vote-aware warn dropped	killed
link-aware warn dropped	killed
both guards narrowed to TypeError, rethrow the rest	killed
trailing .catch deleted	killed
:654 step guard deleted	killed (expected 'failed' to be 'reply')
:1150 reflection-input guard deleted	killed
:1150 guard's warn dropped	killed

The single survivor is an equivalent mutant: catch { return; } → catch { candidates = []; } in the vote-aware guard, whose very next line is if (candidates.length === 0) return;.

The three-ids detail in the link-aware partial test is load-bearing, not incidental: minCandidates defaults to 2, so with only two ids a truncated list of one is dropped by the length gate whether the guard returns or falls through — the fall-through mutant survived that version.

npm run lint                                     clean (tsc --noEmit)
npx vitest run src/memory src/agent src/runtime   75 files / 975 tests passed
full suite, branch vs origin/main                 +15 tests, same single pre-existing
                                                  failure (src/sidecar/send-message-concurrency)

git merge-tree clean against origin/main (92515d3, v0.5.5).

Deliberately out of scope

• The bootstrap wiring of the two decorator loggers is not pinned by a test. Deleting logger, from bootstrap.ts:1866 / :1953 passes the whole suite. The guards still contain the throw either way — only the reporting would go quiet — and a runtime-level pin would need a full createAgentRuntime harness driving a real reflection. Called out rather than hidden; a maintainer may want it anyway.
• Shutdown still does not drain. abortPending() signals and returns; after this PR a shutdown mid-reflection silently discards the vote/link work instead of crashing. A real drain() is a maintainer call, so this PR fixes the comment rather than the semantics.
• The crash reporter still receives an unhandledRejection for anything else that escapes a fire-and-forget path. This closes the reflection one rather than adding a blanket process-level swallow, which would hide real defects. Every other bare void in src/agent, src/memory, src/runtime was checked: memory-store.ts:441 is total-catch by construction (embedding-writer.ts:54, "Never throws"), consolidator-job.ts:239 and bootstrap.ts:2934 already carry .catch.
• A thrown value whose String() conversion itself throws would still escape the new .catch callback. That shape (err instanceof Error ? err.message : String(err)) is used at ~183 non-test sites in this repo; making it safe is a repo-wide change, not this PR's.