Distillation

Date: Sep 17, 2026

• 🟡 (00:49) Diagnostic run confirmed the interrupted Step.Started path leaves a SessionExecutionTable claim present in phase "cancelling" rather than clearing it: assistant_message_id="msg_0acd6d642001C0tvg1ECbHw6ZG", assistant_seq=3, expires_at=30000, id="142fe6f0-cf21-4763-b6df-e6a897ed1359", owner_id="ff35580f-a135-4f4b-8c2a-c32125ad0dfc", session_id="ses_runner_test", time_created=0, recovery_error=null.
• 🟡 (00:49) Diagnostic test SessionRunnerLLM > settles cancellation when Step start notification is interrupted failed at packages/core/test/session-runner.test.ts:4041, where SessionExecutionTable was expected to equal [] but retained the "cancelling" claim. Results: 0 pass, 109 filtered out, 1 fail, 3 expect() calls; 1 test across 1 file in 3.81s, with the failing test taking 859.33ms.
• 🟡 (00:49) Assistant identified the robust fix boundary as EventV2, not cancellation cleanup: publisher memory must be updated after the durable transaction commits but before post-commit notification becomes interruptible.
• 🟡 (00:49) Assistant proposed adding an internal post-commit hook that runs uninterruptibly between transaction commit and listener notification, then moving assistant-start and terminal publisher-memory flags into that hook. Intended outcome: eliminate both Step.Started and Step.Failed interruption windows without making listeners uninterruptible.
• 🟡 (00:50) Inspection of packages/core/src/event.ts:118-124 showed PublishOptions currently has id?: ID, metadata?: Record<string, unknown>, location?: Location.Ref, and commit?: (seq: number) => Effect.Effect<void>. The existing commit hook is documented as a local operational projection committed atomically with a new durable event and not replayed or serialized.
• 🟡 (00:50) Assistant refined the hook semantics: afterCommit should run only for a newly committed durable event, never during replay, and before listener notification. Durable projection remains in commit; afterCommit is limited to synchronizing publisher memory with the committed fact.
• 🟡 (00:50) Inspection of commitDurableEvent() in packages/core/src/event.ts:205-367 showed its current signature accepts commit?: (seq: number) => Effect.Effect<void>. Inside an Effect.uninterruptible region, it runs an immediate database transaction, applies registered projectors, calls commit(seq) at line 323, updates EventSequenceTable, inserts into EventTable, then publishes wakeups to pubsub.durable for a newly committed event.
• 🟡 (00:51) Search found the relevant publishEvent() invocation at packages/core/src/event.ts:427; implementation changes for afterCommit had not yet been shown or tested.