fix(cmux-next): Home's dock takes tabs once the tree reports its ids, not at the next connect (FC-1 follow-up)

Merged
LA
5d ago
+102-7

Summary

Home's dock now takes tabs as soon as the tree reports its ids. Before, it waited for the next connection, so the dock could take no tab for a whole launch.

FC-1 follow-up (fuzz catalog). HomeDock pins Home's dock in its dock move, then lets other tabs in with a separate column.update {allow_tabs: true} (HomeDock.allowTabs). That request names the dock's screen and pane by their resource ids. When the tree had no ids for them yet, the step returned "home dock allow_tabs waits for resource ids", and only the next connection tried again. Until then the dock took no tab at all:

  • every new tab aimed at it was refused (dock-column-pinned, as FC-1's diagnostic job 461a988b39553e691602fe76 logged);
  • or, with #30676, every new tab aimed at it had to open beside it;
  • a tab dragged onto it was refused.

Fix (Packages/macOS/CmuxNext/Sources/CmuxNextHomeEngine/HomeDock.swift): when the ids are missing, the step starts one wait on the store's records (ObservationStream, no timer, no retry loop). When the page's screen and pane first have their ids, the step runs again. For the store Home (HomeService.dock), a later step (a reconnect's) replaces the wait. A window Home makes a new HomeDock per connect (WindowHomes.ensureDock), so each connect with no ids leaves its own wait; each sends one idempotent allow_tabs: true when the ids come, then ends. The wait ends when Home's page is gone. The request is now passed in (AllowTabs), so a test can see it; the app still sends setColumnAllowsTabs(true, ...).

Related: #30503 (landed: the real refusal text), #30676 (a new terminal aimed at a dock that takes no tabs opens beside it).

Changelog

  • Fixed: Home's dock takes dragged tabs right after launch, instead of only after cmux reconnected to its daemon.

Testing

Regression test: HomeDockAllowTabsTests (CmuxNextHomeEngineTests, no daemon). It applies a tree whose Home page is in a pinned dock that takes no tabs and has no screen or pane ids, then runs the step. It expects "waits for resource ids" and no request. Then it applies the same tree with the ids, and expects exactly one column.update for the dock's screen and pane, and the "dock takes tabs" setting recorded.

  • Red at 9874b69598b (test plus the request seam, no behavior change), display worker (gui-session-v1), CMUX_TEST_REQUIRE_GUI=1: step 5e7e52fc0bb67363c299a114 failed with 3 issues: sent.requests.map(\.screen) → [] == [scr_home], the same for the pane, and the setting not recorded.
  • Green at ddcf71c24ce7, display worker cmux13s (gui-session-v1), CMUX_TEST_REQUIRE_GUI=1: step c42815e311f01f1104ed86c8 passed HomeDockAllowTabsTests (1 of 1) and the existing HomeDockOpensTests (10 of 10).
  • Compile: cmux-ci compile-check --app --package CmuxNext --recipe-version 2 job 1342e802aaafd68c920b1d2b passed at ddcf71c24ce7 (CmuxNext, app, cmux-tui).

Observed / Not run

  • Observed: the red and green display steps and the compile-check above, and prepush-gate.py with no new violations.
  • Follow-ups from the review (not in this PR): a comment on why the wait holds HomeDock strongly across its await; removePersistentDomain for the test's UserDefaults suite; a continuation signal instead of the Task.yield loop; tests for the wait's replacement and its end when the page goes.
  • Not run: a first-5s bench launch that shows the ids arriving late and allow_tabs then applied (FC-1's diagnostic log had no HomeDock step lines); the full CmuxNext suite; a dogfood build.

No capture: no visible change beyond Home's dock accepting tabs as it already should.

perf claim: none