Retry S3 ConditionalRequestConflict instead of reporting duplicate chunk

[TheSilkky]

Retry S3 ConditionalRequestConflict instead of reporting duplicate chunk

Priority

P1

Type

bug

Labels

Suggested GitHub labels:

• backlog
• bug
• go
• deployment
• testing

Branch scope

• Current branch: develop
• Current HEAD: 3555d1fd531ecd4b51b85779618bf4717514aa25
• Target branch: develop
• Original reviewed branch/ref: upgrade-codex-reports-and-repo-full-validation-security-review
• Original reviewed commit SHA: e609ff86028c81bd149839e03d1ffc0eb2ee9e4a
• Merged source pull request: #378
• Target release/version: unreleased
• Scope classification: release-blocker-current-branch
• Revalidation status: Revalidated against develop at 3555d1fd531ecd4b51b85779618bf4717514aa25 on 2026-07-12; repeat if develop moves before issue creation.

Summary

Distinguish a retryable S3 conditional-operation conflict from an immutable-object precondition failure so clients are not told that transient storage contention is a permanent duplicate.

Context

The optional S3-compatible backend currently groups two different conditional-write outcomes under one already-exists result. Public AWS documentation distinguishes the retryable conflict response from the precondition response that establishes an existing key.

Existing S3 and backend-parity work in issues #94, #151, and #159 is adjacent but does not track this response-mapping behavior. The repository has no s3 label, so this draft uses existing go, deployment, and testing labels.

Proposed change

Handle precondition failure and conflicting-operation failure separately. Preserve immutable duplicate behavior for the existing-object case. Apply a documented bounded retry for the retryable case or return a safe retryable operational error through the application layer.

Acceptance criteria

• Unit tests distinguish SDK error codes and raw HTTP responses for the two conditional-write outcomes.
• Existing-object precondition failure preserves immutable no-overwrite and duplicate behavior.
• A retryable conditional conflict is retried within a documented bound or returned as a retryable operational failure.
• A retryable conditional conflict is never classified as a duplicate solely from its status code.
• A disposable S3-compatible test exercises the application mapping.
• Logs and responses do not expose object keys, stored paths, request data, credentials, private endpoints, or uploaded bytes.

Tests / validation

• Run gofmt on changed Go files.
• Run go test ./...
• Run go vet ./...
• Run focused S3 storage and HTTP mapping tests.
• Run the approved disposable S3-compatible validation.
• Run git diff --check.
• Revalidate against the target branch before public issue creation.

Out of scope

• Weakening immutable no-overwrite storage behavior.
• Adding provider-specific deployment automation.
• Exposing object identifiers, bucket details, stored paths, or private endpoints.
• Redesigning the upload protocol or unrelated upload-protocol or persistence behavior.
• Including private security findings or reproduction material.

Notes

Report reference: docs/reports/2026-07-10-proofline-unreleased-technical-review.md, public finding F-006.

Open dependency pull requests that update the AWS SDK are not substitutes for this application-level behavior change.