You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ce3ba86
Browse filesBrowse the repository at this point in the historyBrowse files
fix(reactor): open a message run when an approval resumes a parked call
A run opens only when the loop dequeues message.received, and a
correlated approval never becomes one. A parked call rehydrated by a
new reactor has no run from the process that parked it, so its
approval re-dispatched the call and re-inferred with no run open, and
consumers that treat no open run as idle could rebuild the agent under
the running continuation.
The approval now opens a run keyed on its own message id when none is
open. A resume inside the still-open parking run is unchanged.
Copy file name to clipboardExpand all lines: vendor/intx-inference/PATCHES.md
+33Lines changed: 33 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -498,6 +498,38 @@ batch committed); the turns still reach disk segments, so only the cycle's
498
498
manifest records and metadata staging stay uncommitted. Intentionally not
499
499
committed; re-verify after upstream doom-loop accounting changes.
500
500
501
+
## reactor-ts-resume-opens-message-run
502
+
503
+
`reactor.ts` — A correlated approval that resumes a parked call opens a
504
+
message run when none is open. `tryCorrelate`, after the `redispatch` or
505
+
`error_result` dispatch has consumed the pending operation and enqueued the
506
+
continuation (and before `message.correlated`), calls `openMessageRun` keyed
507
+
on the approval message's `messageId`. The re-dispatched call and its
508
+
continuation then run inside a normal `message.run.started` /
509
+
`message.run.ended` bracket, closed by the usual reply/wait/done terminal or
510
+
a failure. When a run is already open (the live case, where the run that
511
+
parked the call is still open) nothing changes: the resume continues that
512
+
run and no second bracket opens. The `gate-cleared` mode (an async-marker
513
+
operation with no suspended call) is untouched.
514
+
515
+
Upstream opens a run only when the loop dequeues `message.received`, and a
516
+
correlated approval never becomes one. A pending operation rehydrated by a
517
+
new reactor (restart, `corbits resume`, an agent rebuild) has no run from
518
+
the parking process, so its approval drove tool execution and inference
519
+
with no run open. Consumers that treat "no open run" as idle (the TUI defers
520
+
agent reloads to `message.run.ended`) then saw the session as idle mid-call
521
+
and could rebuild the agent under the running continuation. The
522
+
`message.run.started` doc comment in `@intx/types` still describes the
523
+
dequeue-only trigger; it is left verbatim.
524
+
525
+
**Disposition:** Promotion candidate. Upstream's run bracket has no owner
526
+
for a resume that outlives the run that parked it.
527
+
**Removal path:** Upstream PR opening a message run for a correlated resume
528
+
when none is open.
529
+
**Re-carry:** new at this patch; sits between the `tryCorrelate` dispatch
530
+
switch and the `message.correlated` emit, inside
531
+
#reactor-ts-atomic-approval-acceptance's claim. Re-verify after upstream
532
+
changes to correlation dispatch or the run-bracket helpers.
501
533
## reactor-ts-skip-unchanged-history
502
534
503
535
`reactor.ts` — Skip re-serializing unchanged history on checkpoint.
@@ -728,6 +760,7 @@ revisit point is the next vendored sync (see `docs/VENDORING.md`).
728
760
| harness-ts-inactivity-on-semantic-progress | Gate the inactivity watchdog's re-arm on parsed events, not raw SSE bytes | Alexander Guy <alexander.guy@pm.me> | This ledger (#harness-ts-inactivity-on-semantic-progress) | Next vendored sync |
729
761
| reactor-ts-correlating-ids-leak | Wrap `tryCorrelate` in try/finally so `correlatingIds` clears on success dispatch paths | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-correlating-ids-leak) | Next vendored sync |
730
762
| reactor-ts-tool-cycle-turns-only (supersedes reactor-ts-checkpoint-after-tool-cycle) |`executeTools` writes turns to store segments only and defers the cycle commit to terminals; metadata rides along only when a resolved approval dropped a pending operation | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-tool-cycle-turns-only) | Next vendored sync |
763
+
| reactor-ts-resume-opens-message-run | Open a message run when a correlated approval resumes a parked call and no run is open | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-resume-opens-message-run) | Next vendored sync |
731
764
| reactor-ts-skip-unchanged-history (+ reactor-ts-last-written-turns-revision) | Skip `contextStore.writeTurns` when `getTurnsRevision()` is unchanged | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-skip-unchanged-history) | Next vendored sync |
732
765
| reactor-ts-compact-publish-then-memory | Persist compact blobs, stage `writeTurns`, commit, then `replaceTurns` so memory stays on the old generation until publication | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-compact-publish-then-memory) | Next vendored sync |
733
766
| reactor-ts-after-checkpoint-director-only | Gate `afterCheckpoint` on `hasOverride` so auto-commits do not emit it | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-after-checkpoint-director-only) | Next vendored sync |
0 commit comments