Dashboard › opencode › Distillation
2ee236a1-a175-4441-994f-eaf781a545c7["lore_tm_v1_1Kt3MFwgwLb4nWS8JYcpoYWZBUo4KTw-EMgyJ4VUoUs","lore_tm_v1_kWR_pZiiFc5yPuH6_XxAwWkjHaEnq9MasYFIv5y16Gs","lore_tm_v1_m4qC4_dGAyZ2P1eK_zt0pkaW5yk083Aw9cSqiPbe3ys","lore_tm_v1_LL88UWI2S4LEm3pGYrIjzW83fW3xfDsZVvsAa13g5-Y","lore_tm_v1_Qm0xXdnDOnwSyXZYtAHKhgLR29uwNGq--7ygw8lOZ3o"]
Date: Sep 16, 2026
packages/core/src/session/execution/claim.ts:25-31 showed claim fencing requires exact session_id, execution id, owner_id, and expires_at > now.packages/core/src/session/execution/claim.ts:38-52 showed SessionExecutionClaim.update() renews a matching unexpired claim to expires_at = now + SESSION_EXECUTION_LEASE_MS; failure to update dies with SessionExecutionClaim.Lost.packages/core/src/session/execution/claim.ts:54-63 showed SessionExecutionClaim.clear() deletes only the exact matching unexpired claim and dies with SessionExecutionClaim.Lost if no row is deleted.packages/core/src/session/execution/claim.ts:65-66 showed SessionExecutionClaim.transaction() opens an immediate database transaction, renews the claim first, and only then executes the supplied effect.packages/core/src/session/execution/claim.ts:33-37 documents the operational timing requirement that SESSION_EXECUTION_LEASE_MS remain larger than maximum deployment clock skew plus one renewal interval; execution IDs provide immediate fencing after takeover.packages/core/src/session/execution/local.ts:23-47 showed each process generates one random ownerID; each drain generates a random executionID and atomically inserts a session_execution row with phase "ready" and expiry now + SESSION_EXECUTION_LEASE_MS; .onConflictDoNothing() prevents ordinary overwrite when the session already has an execution row.packages/core/src/session/execution/local.ts:48-63 showed a newly acquired execution selects at most one recovery row for the same Session where wake_pending=true and recovery_error IS NULL, ordered deterministically by ascending time_created and then ascending execution_id; its continuation_message_id is passed to the runner.packages/core/src/session/execution/local.ts:64-99 showed execution races the runner against claim renewal repeated every SESSION_EXECUTION_LEASE_MS / 3; successful exit clears the exact claim, while failed exit preserves rows in phase "unknown" or "continue" and preserves interrupted rows unless their phase is "safe".packages/core/src/session/execution/local.ts:103-133 showed interruption first renews the exact claim, forks repeated renewal every one-third lease interval, interrupts the coordinator, and attempts exact-claim clearing. A SessionExecutionClaim.Lost during clearing is tolerated only when no current execution row remains for that Session; otherwise the defect is rethrown.packages/core/src/session/execution/local.ts:139-160 showed the local execution layer loads the Session from SessionStore, dies if the Session is absent, runs runner.run({ ...claim, force, recoveryInputID }) in the Session’s location service, and depends on Database.node, SessionStore.node, and LocationServiceMap.node.packages/core/src/session/recovery.ts showed recovery scanning uses exact constant BATCH_SIZE = 100.packages/core/src/session/recovery-id.ts:3-6 showed deterministic recovery IDs: message(executionID, assistantMessageID) preserves an existing assistant message ID or generates msg_recovery_${executionID}; continuation(executionID) generates msg_recovery_continue_${executionID}.