Skip to content

fix(orchestrator): tolerate unsignable uploads on a layer cache hit - #3633

Closed
michalsuba-e2b wants to merge 2 commits into
mainfrom
feat/layer-upload-cache-hit-tolerance
Closed

michalsuba-e2b wants to merge 2 commits into
mainfrom
feat/layer-upload-cache-hit-tolerance

Conversation

@michalsuba-e2b

@michalsuba-e2b michalsuba-e2b commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

No description provided.

A cache hit needs no upload URL, but InitLayerFileUpload minted one before
checking Exists, so any provider that cannot sign an upload URL for an
external client failed every COPY instruction — including the ones whose
layer files were already cached. Azure is that provider: Put Blob requires
the x-ms-blob-type request header, which a SAS cannot carry.

Exists now runs first and a signing failure is fatal only on a miss, and only
for the typed ErrSignedUploadURLUnsupported sentinel so a broken credential
still surfaces. Cache misses on Azure keep failing until signed uploads land.

GCS, S3 and the filesystem provider are unchanged: they still return the URL
on a hit, which is what the SDK gates forceUpload re-uploads on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@michalsuba-e2b
michalsuba-e2b marked this pull request as ready for review September 14, 2026 07:36
@e2b-dev e2b-dev deleted a comment from michalsuba-e2b Sep 18, 2026
@jakubno
jakubno deleted the feat/layer-upload-cache-hit-tolerance branch September 18, 2026 10:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant