NEXT: test an iPhone upload over 100 MiB end to end

TE
7d ago
+469-20

Leo: "well i just think we can improve it a fuckton more than it is now... it's slow it's bad it belabours the point in too many tooltips it's ugly in places it doesn't even work in places there's lots of functionality that needs to get in"

Head 6cd71e8401196852b50f8308c22a82229f7ee5c6: #26959 has landed, so this branch merged feat-cmux-next (e7ab659e) and now carries only the end-to-end probe, the lazy text preview, and fixes for the two findings of the review at 715e05cc. (1) A Mac close now marks the phone's channel sender closed and wakes a send waiting for room (link.rs), so an upload the Mac refuses before reading stops streaming instead of sending the whole file and then falling back. Regression: the_peers_close_stops_our_sends. (2) A newer attachment of a name also replaces the listed artifact's kind (SessionArtifacts.swift). Regression: theNewerAttachmentOfANameTakesItsKind. Small disk-backed text attachments now preview as text, so SessionArtifactsDiskAttachmentTests expects text. Independent review: SHIP at this head.

Earlier: stacks on #26959 (iPhone: stream uploads, no cap); host support #26954 is merged. Current head ca8599c2d960599b4bbcca45274282c3e72da0ab includes the updated upload branch and fixes the reviewed picked-text preview regression. Small disk-backed text, HTML, Markdown and code are decoded lazily for rendered/source previews; large files use Quick Look with no inert Source toggle. Pasted images above the 24 MiB inline decoding budget are sent as disk-backed file attachments, not inline ACP image blocks; there is no attachment/upload size cap. LocalFileScopeTests covers small text across four extensions and large-file fallback.

Independent review: SHIP at ca8599c2d960599b4bbcca45274282c3e72da0ab; focused fleet tests and the pair-e2e upload probe are pending at this exact head. Follow-up items are friendly FileHandle errors and closing scopes after decoding; neither blocks this reviewed head.

Leo: "Attachments take arbitrarily large files of any type; there is no size cap."

What it proves

An iPhone upload past the old 100 MiB cap reaches the Mac whole, through the real client and the real host.

  • Simulator, end to end (the pair-e2e rig, scripts/ci/cmux_next_pair_e2e.py). After the phone pairs with the tagged Mac by QR code, an upload leg runs. The rig writes a sparse file of 157,298,985 bytes (150 MiB + 12,345) into the app's container, with marked 4 KiB pages at the start, middle and end. It relaunches the app with a DEBUG-only launch argument (UploadProbe, #if os(iOS) && DEBUG). On the first link served after pairing, the app streams the file with its own LinkUpload.upload(fileAt:) to the Mac's Chat Folder (agents.chats.roots in the rig's settings, which hostd shares). The leg fails unless:

    • the stored file is in <cwd>/.cmux/attachments/phone-<session>/;
    • it has the same size and SHA-256 as the phone's file;
    • the app's phys_footprint (sampled every 20 ms during the upload) grew by less than a fifth of the file, so no Data of the whole file was ever made.

    A Mac refusal (too_large, forbidden) is reported by its code and fails the run. The leg runs only on a ref that has UploadProbe.swift.

  • Rust, Linux (cmux-mobile-link-ffi/tests/upload.rs). The exported link the app calls (connect_inner, open_channel, ChannelHandle::send) sends to cmux-mobile-host's real upload service over WireGuard and over WebRTC. It sends what LinkUpload sends: string args, then the file read 192 KiB at a time. The test checks the same location, size and SHA-256.

Run

  • Rust (Linux): cd cmux-next-ios/rust && cargo test --locked -p cmux-mobile-link-ffi --test upload
  • Simulator (fleet): cmux-ci run --class simulator --script scripts/ci/cmux-next-ios-sim.sh --ref 924cd232abceb7a5c91a2f0ed6128aecea4f391c --arg pair-e2e --artifact artifacts/ios-sim/evidence.zip. The - upload: line in SUMMARY.md gives the result.

Observed / Not run

  • Observed (on a Linux lane VM, at this head): the Rust test passed, 2 of 2 (WireGuard and WebRTC, 157 MB each, 43 s).
  • Observed, negative control: with base's check (size > 100 MiB ā†’ too_large) put back in receive_upload, both fail with the Mac refused the upload: {"error":"too_large","message":"the file is larger than 100 MB"}.
  • Observed: prepush-gate.py found no new violations.
  • Not run: the Swift side (UploadProbe.swift, and its hook in LiveCoordinator+Links.swift) has not been compiled. This VM can't build Swift; the simulator command above builds it and runs the leg.
  • Not run: the simulator leg itself. The rig's Mac name gate and the Chat Folder route are read from the code, not yet seen on a fleet run.

Changelog

none

CI note: the release-notary rerun fails scripts/whats-new/test_digest.py:89, test_the_repository_highlights_validate, on the old computer-use-live-preview.md highlight. The original base had the same test and assertion failure; the rerun checks out the original PR merge commit, so it retains that old base content. This PR changes no highlights or What's New code. Release-notary and its dependent Guard status are base reds; fleet validation remains required.

Agent session: agent session

šŸ¤– Generated with Claude Code