ci: a CmuxNext suite lane never waits for an active cmux-tui artifacts run

Merged
LA
8d ago
+122-10

Summary

Fleet Mac suite steps (package-test-lane.sh suite Packages/macOS/CmuxNext ..., run-swift-testing-suites.sh) held a Mac for up to two hours and ran no test while the commit's cmux-tui artifacts run was queued or running.

The lane fetches the tree's cmux-tui with CMUX_TUI_TREE_WAIT_SECONDS=0, which is meant to look once: on a miss, the live-daemon suites skip. But off GitHub Actions, wait_for_tree in pin-cmux-tui.sh stretched that 0 to the active-run cap (CMUX_TUI_TREE_ACTIVE_WAIT_SECONDS, 7200 s) whenever an artifacts run for the commit was active. The controller does not let a step set that variable.

Seen on the fleet:

  • 31482fc9e743: waited 7184 s.
  • 036f288649bf: waited 3065 s, then was cancelled.
  • 72dac7f62135: waited 496 s or more, then was cancelled.
  • 0b2b6232e4c8: waited 14 min.

All of them reached this fetch only after the worker's own cmux-tui recipe (hq step_tui.go, 25 min bound) had failed or timed out.

Now a wait of 0 looks once and exits 1 at once. It reads no run state, does not extend the wait and does not poll. Callers with a real wait (app builds 2700 s, workflows 120 s, release) keep the active-run extension unchanged. Dispatch is unchanged.

Testing

  • python3 tests/test_ci_package_lane_suite.py: new check. It runs the real pin-cmux-tui.sh through the lane against an unreachable CDN and a file:// GitHub API that lists one queued run, on the fake clock. Base: FAIL: the lane waited 7200s for the active artifacts run. Head: package-test-lane suite: ok.
  • bash scripts/cmux-next/tests/pin-cmux-tui-run-check.test.sh: new case. Base: fleet, no wait, active run: waited 9s. Head: ok.

Observed / Not run

  • Observed: both tests red on the test commit and green on the fix, here and on perf/chrome-parity.
  • Observed: pin-cmux-tui.test.sh, tree-key-v2.test.sh, reset-stale-submodules.test.sh, pin-cmux-tui-fallback-key.test.sh and pin-cmux-tui-dispatch.test.sh pass (run on the perf copy, where the wait_for_tree diff is the same).
  • Observed: against the real API at 44d0c58bfb6, while its artifacts run 40889589007 was pending, the old pin was still polling at a 420 s timeout. The new pin exited 1 after its single look.
  • Observed: prepush-gate.py reports no new violations.
  • An independent review subagent passed it (SHIP).
  • Not run: a fleet suite step on this branch. The proof step for the same change on perf/chrome-parity is 964c7524a9a2.

Performance

No perf numbers: this changes how long a fleet CI test lane waits for a cmux-tui artifact (a wait of 0 now looks once). It changes no app, daemon or UI code path. "perf" in this description names the perf/chrome-parity branch copy, not a performance change.

Changelog

none


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.


Summary by cubic

Fixes fleet CmuxNext suite lanes holding a Mac for up to two hours while waiting on an active cmux-tui artifacts run instead of doing a single look.

A lane's CMUX_TUI_TREE_WAIT_SECONDS=0 meant to check once and skip on a miss, but on fleet hosts (outside GitHub Actions) wait_for_tree extended the 0 to the 7200 s active-run cap whenever the commit's artifacts run was queued or running. The lane's own fetch only runs after the worker's cmux-tui recipe failed or timed out, so the step ran no tests while a Mac sat idle (observed waits: 7184 s, 3065 s, 14 min).

  • A wait of 0 now looks once, reads no run state, and exits 1 immediately.
  • Callers with a real wait (app builds, workflows, releases) keep the active-run extension unchanged.
  • Adds lane and pin test coverage, both red before and green after; the pin public-fallback case now waits 1 s since a 0 wait reads no runs.