aafe1327793426a62d05aa5030aa5958cf4679a5
Guarantee 1 is "durably stored in the configured bucket before the response completes". The tee sent every chunk straight through, so the client saw the last byte before the multipart upload was completed and well before the manifest referenced it. A client that read a file and immediately failed over to a sealed instance could be told the file had never been seen -- and if either storage phase failed, it had already received a clean 200 over bytes nothing recorded. The tee now runs one chunk behind and releases the final chunk only after the upload completes and the manifest write lands. Content-Length is already on the wire, so a client cannot treat the transfer as complete without those bytes; a storage or manifest failure now ends the body short instead, which is what the client detects and retries on. Costs one chunk of extra latency at the end of a transfer and nothing else: the withheld chunk is bounded by the upstream chunk size, and a disconnected client still has its transfer finished without it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XZG2i4AmfSqE97EJGBVb64
Languages
Rust
81.3%
TypeScript
5.9%
Python
5.6%
Shell
5.4%
CSS
1.6%
Other
0.1%