feat(storage): apply implicit file:// resolution to all top-level URI helpers#92
Merged
Merged
Conversation
… helpers PR #91 wired resolveImplicitFileURI into LoadBucket but the object-level helpers (GetObject, HeadObject, PutObject, DeleteObject, CopyObject, ListObjects, and their *At variants) still called uri.Split directly on raw inputs, so a bare path like "input.json" failed with "bucket not found" even though the same input worked for LoadBucket. This change applies resolveImplicitFileURI at the top of every *At function so all top-level URI-taking helpers behave uniformly; the non-At wrappers and PutObjectAtWriter inherit the fix transitively. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
resolveImplicitFileURIintoLoadBucketsostorage.LoadBucket(ctx, "some-path")would treat a bare path as afile://URI. The intent was for the same to hold for every top-level URI-taking helper, but the fix was only wired into one entry point —GetObject(ctx, "input.json")still failed withbucket not found.resolveImplicitFileURIat the top of every*Athelper:HeadObjectAt,GetObjectAt,PutObjectAt,DeleteObjectAt,CopyObjectAt(bothsourceURIanddestURI), andListObjectsAt. The non-Atwrappers andPutObjectAtWriterinherit the fix transitively.TestCopyObjectsubtests (invalid source URI,invalid dest URI) asserted that the bare string"invalid-uri"should fail; that's exactly the behavior being changed. The remainingbucket not foundsubtest still covers unknown-scheme rejection.Why a per-function fix (not deeper)
registryFunc.LoadBucket: each*Athelper splits the object URI before loading the bucket. ForGetObject(ctx, "input.json"),uri.Splitreturns("", "", "input.json"), so the call intoregistry.LoadBucketis already passing"". Resolution at the registry level is too late.uri.Split: would change semantics for every caller (Split("foo")flipping from("", "", "foo")to("file", "", "/abs/cwd/foo")).uri.Splitis exported and consumed elsewhere; broadening its file-path detection past the existing/,./,../,~rule is a load-bearing change not worth taking on here.Test plan
go test ./storage/...go test -race ./storage/TestImplicitFileObjectURIsexercises Put → Head → Get → Copy → List → Delete with bare-path URIs undert.Chdir(t.TempDir()).TestLoadBucketImplicitFile,TestResolveImplicitFileURI, and fullTestStoragematrix still pass (no behavior changes for explicit URIs —resolveImplicitFileURIshort-circuits on any input containing:).Downstream
Once this lands,
stripes'sresolveSourceURIhelper (which exists only to work around this asymmetry) becomes redundant and can be removed.🤖 Generated with Claude Code