Record physical blob deletion failures without claiming completion
Permission errors are swallowed and metadata says Deleted while bytes remain. Persist retryable failure state.
- Focused work estimate
- 2h 15m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Error handling · Recovery
Estimated field mix
- Storage systems70%
- Site reliability30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
Fictional archive Moss deduplicates generated attachments across documents within each organization. Use local files and transactional metadata stubs.
Setup prerequisites
- Generate duplicate and unique local byte fixtures.
- Create synthetic document references across two organizations.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CBLOB-101 · Separate attachment display names from blob identities
- CBLOB-102 · Scope blob deduplication to the owning organization
- CBLOB-103 · Reject references to incomplete synthetic blobs
- CBLOB-104 · Tombstone unreferenced blobs before physical deletion
- CBLOB-105 · Prevent a new blob reference racing with reclamation
Acceptance criteria
- Successful deletion records acknowledgement
- Failure remains pending
- Already absent file is idempotent success
Implementation constraints
- Do not log attachment contents or paths outside fixture scope.
Verification to include
- Delete fixture
- Inject permission failure
Deliverables
- Deletion result handling and cases
Rollout and recovery
Pause retries on repeated provider faults.
Value of the work
For the engineer: Practice reclamation races and explicit data-lifecycle guarantees.
For the team: Inspect whether storage cleanup avoids broken references and hidden retention.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.