[teamleaderleo]

Part 4 of the rebuild of #23199 and #24070 (adopted by hb-acpmux). Builds on #25386 (merged), and is rebased onto feat-cmux-next.

The queue that brings other machines' daemons to the app's build. Nothing offers it a machine yet: acpmux ssh peers and Cloud machines are the next PRs.

Leo: "BRO CANT YOU JUST LIKE SUSPEND SHIT AFTER A TOOL CALL/TURN THEN JUST GO AND AUTOUPDATE OUR TEAMMATES NEED ACPMUX UPDATING TOO..."

Leo: "OUR SHIT IS HARDLY EVER GOING TO GO IDLE. IT JUST WONT. YOU'LL JUST HAVE TO ACCEPT IT BREAKING AT SOME POINT BUT IT RESUMES WHATEVER IT INTERRUPTED. END OF STORY FOR THE DAEMON UPDATE."

Leo-ask: ask-48bbaec1d4
Leo-ask: ask-061e3574a6

Change

DaemonUpdatePolicy (from #24070 at bd4892c), one per app (shared), fed by offer(_:):

• Trigger: a machine on another commit than the app's bundled build. A dirty bundled build pushes nothing. An urgent machine (a Cloud machine the app refused) goes even with no known build, and goes first.
• Never a move back (new since cmux NEXT: update acpmux ssh peers and Cloud machines to the app's build, also mid-turn #24070): a machine on a build of a later day, or on a build with local changes (someone's own), is left alone. acpmux: Linux hosts keep their daemon on the newest feat-cmux-next build by themselves #24232 made Linux hosts follow feat-cmux-next by themselves, so moving one back to the app's build would only restart it twice.
• No wait for idle. A machine is updated mid-turn as soon as the policy reaches it, and the restarted daemon resumes what it interrupted, as Leo's words above ask (acpmux: Linux hosts keep their daemon on the newest feat-cmux-next build by themselves #24232 made the daemon persist and resume). updateBusyAfter defaults to zero; a non-zero value (idle asks first, mid-turn at the cap) stays an option that nothing sets. cmux NEXT: update acpmux ssh peers and Cloud machines to the app's build, also mid-turn #24070's last version did the same.
• A machine that can't update now (unreachable, another update running) is asked again with backoff: 2 minutes, doubling, at most 30 minutes apart. After 6 hours it is left for the next launch.
• One machine at a time across every source. An id already queued or running is not queued twice.
• One attempt per machine and build (DaemonUpdateLedger). A final outcome (updated, current, rolled back, failed) is kept across launches, so a rollback is not retried before the next build.
• Each step goes to DaemonUpdateBoard. A recorded failure asks for one notice.
• The toggle agent.updatePeers is read before every step, and turning it off empties the queue.

Timers and their stop conditions

• The drain loop. It ends when the queue is empty, which happens when every machine is done, left for the next launch, or the toggle went off.
• The backoff nap (clock.sleep, at most 30 minutes). It ends at its deadline or when a new offer cancels it. Its machines stop after 6 hours of not being able to update.

Tests

DaemonUpdatePolicyTests (fake machines, an auto-advancing test clock):

• an old machine is updated; a machine on the build, of unknown build or nogit is left alone; a dirty bundled build pushes nothing;
• aTargetOnANewerOrItsOwnBuildIsLeftAlone (red first: 03733e8 is cmux NEXT: update acpmux ssh peers and Cloud machines to the app's build, also mid-turn #24070's policy, which updates them; CI at that commit's earlier copy f56f2c5 showed this test failing);
• aBusyTargetIsUpdatedMidTurnOnTheFirstAsk (red first: 59e2fba has these tests on the 10-minute default, and this test fails there; the next commit sets the default to zero);
• withACapANeverIdleTargetIsUpdatedWhileBusyAtTheCap: with the optional cap, idle asks at 0, 2 and 6 minutes, then mid-turn at 10;
• aTargetBusyAlsoWhileBusyIsLeftAfterSixHours: 2, 4, 8, 16, then 11 × 30 minutes, all mid-turn; unrecorded; it leaves the board;
• one at a time;
• a retried machine that reached the build meanwhile leaves the board;
• a failure is recorded and asks for one notice, also after a relaunch; a rollback is retried only on the next build; no binary is not recorded; a machine handled elsewhere leaves no state;
• an urgent machine goes first and doesn't wait behind a busy one's backoff;
• offers are deduped while running; the toggle off runs nothing; a machine offered while the toggle-off is reported still updates.

Observed / Not run

• CI at c7b8f0a (run 40301784433): DaemonUpdatePolicyTests and DaemonUpdateTargetTests passed, among them aBusyTargetIsUpdatedMidTurnOnTheFirstAsk, aFailureWhoseLedgerCannotBeWrittenIsNotRetried and aBundledVersionThatNeverAnswersEndsAtItsBound. The daemon tests passed.
• The swift test job is red the way it is on other PRs today: the test process is killed (exit 143), and the failing tests (AppKit commit boundary, sidebar rows, panel warm-up, browser tab mirror, ActionRunCreated) are in code this PR does not touch and fail on other PRs' runs too.
• Not run: no real daemon or peer was updated.

No capture: no visible UI.

Agent session: big-red
🤖 Generated with Claude Code

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review a417ed5: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr25387 -f ref=lane/hb-daemon-update-policy -f platform=macos -f backend_mode=local

web and size checks: green

Tour of c7b8f0a0ee (run): no media. The tour job failed before the tour ran (build or setup); the run log has the output.

[teamleaderleo]

Owned by hb-acpmux on big-red · session

[teamleaderleo]

Bead cx-405df created for this PR by the cmux coordinator.

[teamleaderleo]

cmux-next / cmux-next checks (god files, concurrency, crash safety, l10n) › Script tests (pin-cmux-tui, embed-cef, ensure-cef store) is red on 11 of 12 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

Review (codex gpt-6-astra xhigh): SHIP at c7b8f0a

[teamleaderleo]

high-signal review link / link is red on 16 of 18 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4032307340502 (35e1c1f88b)
• cmux NEXT nightly 1.0.0-nightly.4032901198601 (079a929b63)