fix(versionsource): surface version creation failures and fix streaming warning#250
Merged
fix(versionsource): surface version creation failures and fix streaming warning#250
Conversation
…ng warning Two related bugs in POST /versionsource: 1. Non-retryable streaming warning in Cloudflare Workers When putVersion sends an HTML body (piped from an S3 GET response) to R2 using If-None-Match: *, R2 can reject the PUT via Expect: 100-continue before reading the body. The S3 GET response stream is then left open and unconsumed, causing Cloudflare Workers to log: "An error was encountered in a non-retryable streaming request." Fix: cancel Body in putVersion's catch block so the underlying connection is properly closed. 2. POST /versionsource silently returns 201 when no version was created putVersion uses If-None-Match: * to write the version snapshot. When R2 returns 412 (version UUID already stored, or a false-positive during Worker cold starts under batch load), the code treated 412 as acceptable and continued to the main document PUT, ultimately returning 201. This made it impossible for callers to detect that no version was written. The API contract for POST /versionsource is "create a version". If no version is created for any reason, the response must be an error. Fix: track versionCreated in putObjectWithVersion and have postObjectVersionWithLabel return 500 when the version PUT did not produce a new snapshot. The main document PUT still runs on 412 (it bumps the version UUID), so a client retry will use a fresh UUID and succeed — matching observed behaviour where re-running the request on affected documents works correctly. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
bosschaert
approved these changes
Mar 11, 2026
adobe-bot
pushed a commit
that referenced
this pull request
Mar 12, 2026
## [1.1.7](v1.1.6...v1.1.7) (2026-03-12) ### Bug Fixes * **versionsource:** surface version creation failures and fix streaming warning ([#250](#250)) ([4ee0dbe](4ee0dbe))
Collaborator
|
🎉 This PR is included in version 1.1.7 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two related bugs in POST /versionsource:
Non-retryable streaming warning in Cloudflare Workers
When putVersion sends an HTML body (piped from an S3 GET response) to R2 using If-None-Match: *, R2 can reject the PUT via Expect: 100-continue before reading the body. The S3 GET response stream is then left open and unconsumed, causing Cloudflare Workers to log:
"An error was encountered in a non-retryable streaming request."
Fix: cancel Body in putVersion's catch block so the underlying connection is properly closed.
POST /versionsource silently returns 201 when no version was created putVersion uses If-None-Match: * to write the version snapshot. When R2 returns 412 (version UUID already stored, or a false-positive during Worker cold starts under batch load), the code treated 412 as acceptable and continued to the main document PUT, ultimately returning 201. This made it impossible for callers to detect that no version was written.
The API contract for POST /versionsource is "create a version". If no version is created for any reason, the response must be an error.
Fix: track versionCreated in putObjectWithVersion and have postObjectVersionWithLabel return 500 when the version PUT did not produce a new snapshot. The main document PUT still runs on 412 (it bumps the version UUID), so a client retry will use a fresh UUID and succeed — matching observed behaviour where re-running the request on affected documents works correctly.