Skip to content

Release viewer route holds when opening and attachment finish - #1159

Merged
trissim merged 8 commits into
mainfrom
fix/route-reader-lifetimes
Oct 23, 2026
Merged

trissim merged 8 commits into
mainfrom
fix/route-reader-lifetimes

Conversation

@trissim

@trissim trissim commented Oct 23, 2026 •

Copy link
Copy Markdown

Paired with Core OpenHCSDev/agent-comms#2860. Core head 36542eb3cf42bce729ae3da7565e75bddc2a201d; Toad head bc51609. They land together under the commander's paired order.

An old viewer cannot read a root that a new runtime owns. Rather than turn that correct refusal into FailedObservation, the root's attachment result now hands the viewer to the recorded owner:

  • comms_root.py:372-390: RootRuntime.attachment(...).proceed selects the existing attach body or app.succeed_onto before Comms is constructed. No prefix comparison or exception translation lives here.
  • app.py:216-218: succeed_onto calls from the preparation worker onto the app thread, exits with Succeeded(runtime), then cancels that old worker so it cannot continue opening the root.
  • application_lifetime.py:25-45: the existing lifetime owner declares TerminalOutcome, Ended and Succeeded. Ended prints the existing VersionMonitor notice. Succeeded validates its supplied runtime and execs its toad entrypoint with sys.argv[1:] and runtime.environment(os.environ), like Core's claimed bridge replacement.
  • app.py:198-214: the app uses Textual's single return-value slot, initialized to Ended; exit converts Textual's omitted result into Ended and preserves an explicit Succeeded. The typed return_value reads that same slot. There is no second outcome store or isinstance dispatch.
  • cli.py:26-40: existing crash persistence and nonzero error handling remain; the returned terminal outcome owns finish().
  • Earlier source changes release service-opening and ACP-attachment route borrows at the end of those operations, not at the end of the viewer/process lifetime.

Startup answer: NO, this head does not reopen the saved open-tab roster. app.py:440-444 calls ApplicationLifetime.start, whose application_lifetime.py:149-157 opens home or one explicit --session. TabOrder starts empty at tab_order.py:14. #1162 is still draft and owns roster restoration; none is built here.

Both mains were merged and both published heads match ls-remote. No tests, app launch or practice install ran in Drafts; the review fork runs the pair. Earlier copied-app results used old heads: idle installs succeeded, but history remained Loading messages and replacement refused the old runtime. Those old observations do not prove this new handoff.

Assumed: succession is entered from the existing preparation worker; Textual's normal shutdown retires existing app resources; the recorded runtime contains the paired toad executable; argv/root selection survives exec through its existing arguments/environment; open-tab restoration remains #1162. The core prefix/maintenance guard remains authoritative.

@trissim
trissim marked this pull request as ready for review October 23, 2026 20:33
Copilot AI balanced review requested due to automatic review settings October 23, 2026 20:33

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

@trissim
trissim merged commit f1a7798 into main Oct 23, 2026
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants