Cloud: a legacy link's startup logs each step and bounds its waits
AU
1d ago+47+47+01234567890123456789-9-9-0123456789
On NEXT nightly (build 4157013432001, link_route: legacy), a new machine ran and its daemon listened, but the app never connected. There was no wg hub or remote connect child and no error in the log, and after 180 s the start card said "didn't connect. Retry once it's online". A further connect also did nothing. The stuck step is not known yet, which is why this PR exists.
What changes
CloudMachineLink.startandCloudTunnelHub.startlog each step at notice, so it is persisted.- A legacy connect logs each way it can stop before the link starts, and when its hop starts the daemon. A remote start that returns early logs why.
- The attach endpoint wait (95 s) and the tunnel hub wait (170 s) use
SandboxDeadline.race, becausewithDeadlinewould wait for work that ignores cancellation. Both bounds sit past their steps' own deadlines (token read 60 s, requests, hub first line), so only a stuck step trips them. A stuck step then fails through the existingnoteLinkanddaemon unavailablepaths, with its name.
This does not fix the connection bug. It should name the stuck step on the next Nightly.
Verification
cmux-ci compile-check --appjob 9854ec0b14a4d38385ad9ec0 passed at d169c731b5131d3197416f1d699b03140cddda0a.- UNVERIFIED: not run against a stuck link. No tests were run or added.
🤖 Generated with Claude Code