cloud: a connect waits in the app server for its machine to run; delete Swift untilRunning

Merged
TE
2d ago
+275-72

Part of M12 in the Cloud architecture plan: create, connect and redial move out of Swift into the Rust Cloud app server, and Swift only subscribes to events. Leo (2026-11-04): "and moving off swift into rust for next's cloud" / "you guys should be willing to remove code rewrite do large scale refactors".

What changes

  • Rust (first-party-apps/cloud/server). A cloud.machine.connect for a machine that doesn't run yet no longer answers link_down "connect again when it runs". That covers a new machine that is still binding (cloud.machine.not_bound, retryable) and one that is starting. The serve loop parks the op (link/park.rs, new Wait::Running) and runs it again in two cases:

    • the projection shows the machine running, either from a team cloud.machine.upsert or from another op's answer;
    • its next read is due (1 s apart for the first 20, then 3 s).

    Each read is a single connect_info of that one machine, never a list. After MAX_READS (45 reads, about 95 s) it gives the old starting answer, so the reply still lands inside the app's 120 s connect bound. Cancelling the op drops it and its timer. Direct (non-loop) callers keep the old answer.

  • Swift. Deletes CloudMachineSession.untilRunning, which forced up to 80 list reads per first send, along with its call in CloudMove.connected and its test aStartWaitsForANewMachineToRun. The app-link connect now waits in the server.

Tests

tests/serve_connect_wait.rs covers four cases:

  • the running upsert answers a waiting connect (no timer fired, no list read);
  • a due read answers it;
  • a machine that never runs answers starting after the last read, with one timer per read;
  • a cancelled wait answers cmux.op.cancelled and leaves no timer.

The full server suite, clippy -D warnings and fmt run on the fleet, and so does the CmuxNext compile check.

šŸ¤– Generated with Claude Code

Agent session: agent session