Large sync payloads can now go straight to a filestore, falling back if the server refuses.
What's wrong with this entry?
Directory sync gains a third way to move data alongside the existing row and file carriers: a direct lane that uploads content straight to a filestore, addressed by a sha256 of the content and keyed off the session id. There is no client flag for it. The client offers it for outbound payloads above a minimum size, and a server replying unsupported marks the lane refused and puts it on a cooldown before it is tried again, falling back to the row lane meanwhile.
- New client calls begin an upload, commit it, and fetch a download descriptor against per-session synced_file endpoints, returning a filestore url, id and JWT plus an upload path.
- Transfers are resumable:
expiredornot_foundresponses trigger a retry, and inbound transfers have their own size cap. - Repeated non-429 failures back the lane off; a server that never implements it costs one attempt per cooldown window.
- The lane is wired live at both places directory sync builds its transport, so whether it does anything is decided entirely by the server.
/v1/code/sessions/${n}/synced_file/uploads/commit, dir-sync: direct commit refused: the declared name holds other bytes
Strings lifted out of the shipped bundle, so the claim above can be checked against them.