fix(cmux-next): await FolderChanges.events() in the machine consent watch (base Release compile red)

Closed
TE
8d ago
+5-5

Fixes the base red on feat-cmux-next: cmux-next/compile (SwiftPM Release, -Onone) has failed on every landing from 00d6d54f6 (#26517) on, 17 in a row as of 0da5bc33f. While it is red, no NEXT nightly can build a newer commit, so the feed falls further behind the tip on every landing (Leo: "it is unacceptable to have nightlies >30min out of date").

Cause

#26517 made FolderChanges.events() async (it returns once its watches are registered). #27223 landed alongside it, and its MachineConsentChanges.events(armed:) in JoinConsent+App.swift calls FolderChanges(...).events() without await. Each PR compiled on its own base. Together they don't compile.

Change

  • MachineConsentChanges.events(armed:) is now async, and it awaits the folder's registration before it arms the files and runs armed. That keeps the documented order (folder, then files, then armed, then the first element) and gets #26517's stronger readiness guarantee.
  • Its one app caller (JoinConsent+App.swift:138) and the two JoinConsentTests call sites add await. The package enables NonisolatedNonsendingByDefault, so the non-escaping armed closure stays on the caller's actor.

5 lines changed. No behaviour change beyond the readiness await.

No capture: a compile fix with no visible change. The consent watch arms the same files in the same order, and no view changes.

Risk

Low. A compile fix on a type-checked call path. The fleet Release compile on this head is the check.

Agent session: agent session

šŸ¤– Generated with Claude Code