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 2ac29d2
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
+34Lines changed: 34 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -531,6 +531,39 @@ skip calls that already have a result.
531
531
branch. Re-verify after upstream changes to rehydration or to the ask-rail
532
532
timeout result.
533
533
534
+
## reactor-ts-resume-opens-message-run
535
+
536
+
`reactor.ts` — A correlated approval that resumes a parked call opens a
537
+
message run when none is open. `tryCorrelate`, after the `redispatch` or
538
+
`error_result` dispatch has consumed the pending operation and enqueued the
539
+
continuation (and before `message.correlated`), calls `openMessageRun` keyed
540
+
on the approval message's `messageId`. The re-dispatched call and its
541
+
continuation then run inside a normal `message.run.started` /
542
+
`message.run.ended` bracket, closed by the usual reply/wait/done terminal or
543
+
a failure. When a run is already open (the live case, where the run that
544
+
parked the call is still open) nothing changes: the resume continues that
545
+
run and no second bracket opens. The `gate-cleared` mode (an async-marker
546
+
operation with no suspended call) is untouched.
547
+
548
+
Upstream opens a run only when the loop dequeues `message.received`, and a
549
+
correlated approval never becomes one. A pending operation rehydrated by a
550
+
new reactor (restart, `corbits resume`, an agent rebuild) has no run from
551
+
the parking process, so its approval drove tool execution and inference
552
+
with no run open. Consumers that treat "no open run" as idle (the TUI defers
553
+
agent reloads to `message.run.ended`) then saw the session as idle mid-call
554
+
and could rebuild the agent under the running continuation. The
555
+
`message.run.started` doc comment in `@intx/types` still describes the
556
+
dequeue-only trigger; it is left verbatim.
557
+
558
+
**Disposition:** Promotion candidate. Upstream's run bracket has no owner
559
+
for a resume that outlives the run that parked it.
560
+
**Removal path:** Upstream PR opening a message run for a correlated resume
561
+
when none is open.
562
+
**Re-carry:** new at this patch; sits between the `tryCorrelate` dispatch
563
+
switch and the `message.correlated` emit, inside
564
+
#reactor-ts-atomic-approval-acceptance's claim. Re-verify after upstream
565
+
changes to correlation dispatch or the run-bracket helpers.
566
+
534
567
## reactor-ts-skip-unchanged-history
535
568
536
569
`reactor.ts` — Skip re-serializing unchanged history on checkpoint.
@@ -762,6 +795,7 @@ revisit point is the next vendored sync (see `docs/VENDORING.md`).
762
795
| 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 |
763
796
| 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 |
764
797
| reactor-ts-skip-answered-parked-call | Drop pending operations whose parked call already has a result at rehydration, and inject no approval-timeout result for such a call | Alexander Guy <alexander.guy@pm.me> | This ledger (#reactor-ts-skip-answered-parked-call) | Next vendored sync |
798
+
| 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 |
765
799
| 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 |
766
800
| 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 |
767
801
| 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