S3 DeleteObjects omits delete-marker metadata from successful versioned deletes
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- postgresql, typescript
Research direction
Start in S3ProtocolHandler.deleteObjects and inspect the storage layer’s successful delete result and the focused handler regression test mentioned in the issue. Check how versioned deletes without a VersionId expose the created marker fields; done means the Deleted response includes DeleteMarker: true and DeleteMarkerVersionId for that entry, with the regression test passing.
Written by the indexing model from the issue text.
Description
Problem
When DeleteObjects removes a key from a versioned bucket without a VersionId, the storage layer returns the newly created delete-marker row, including its marker version. S3ProtocolHandler.deleteObjects reduces successful entries to { Key }, so the S3 response omits DeleteMarker and DeleteMarkerVersionId. This prevents SDK callers from identifying the marker created by their request.
Reproduction
In a versioned bucket, create an object and delete it with DeleteObjects without specifying a VersionId. The successful Deleted response entry contains only the key. A focused handler regression test against current master fails because the marker fields are missing.
Expected behavior
For a successful deletion that creates a delete marker, return DeleteMarker: true and the created DeleteMarkerVersionId in the corresponding response entry, as defined by the S3 DeleteObjects response contract.
- Dominant language
- TypeScript
- Stars
- 1.3k
- Forks
- 318
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 102
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/storage
-
The sample application in storage article points to wrong URLMay be free again @prasadf18 claimed this 206 days ago, and no pull request is open. Opendocumentation
Difficulty 1/5 Under an hour Newbie friendliness 62/100
supabase/storage#557 · 1 comment ·
Maintainers usually reply within 1 day
-
Local image transformations fail for filenames containing @Possibly taken @hsusul claimed this 2 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
File backend accepts weak If-Match validators as strong matchesPossibly taken @hsusul claimed this 2 days ago. Open
Difficulty 3/5 Half a day Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
S3 POST uploads reject keys that use the ${filename} variablePossibly taken @hsusul claimed this 3 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
S3 PutObject and CompleteMultipartUpload ignore If-None-MatchPossibly taken @vignesh-chaturvedi claimed this 3 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 30/100
Maintainers usually reply within 1 day
All issues in supabase/storage
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
LucasSantana-Dev/Lucky#2951 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
danielmiessler/LifeOS#2567 ·
Maintainers usually reply within 9 days
-
refactor(react-pi): classify base64 images with core's parseBase64Possibly taken @jimmyallinai claimed this today. Openmaintenance
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
assistant-ui/assistant-ui#10293 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
brijeshb42/monaco-vim#175 ·