- Store-then-publish in
ClaimCheckPublisher can leave orphaned objects if publish fails after a successful put
- The
trogon-claims bucket currently uses ..Default::default() with no max_age, so orphans accumulate forever
Design considerations
Two cleanup paths are needed:
Happy path: consumer deletes after resolve
resolve_claim reads the object from the store. After successful resolution, the consumer should delete the object — that's the normal claim check lifecycle (put → publish claim → resolve → delete). This requires adding an ObjectStoreDelete trait and wiring it into resolve_claim or letting the caller handle deletion after consuming the payload.
Failure path: orphaned objects
When publish fails after a successful put, no claim message exists to reference the object. Options:
- TTL (recommended first step): Set
max_age on the bucket (e.g. match stream's 7-day retention). Simple, predictable. Orphans expire automatically. Trade-off: storage cost for the TTL window.
- Reaper process (if storage pressure warrants): Background job lists objects in the bucket, cross-references against JetStream messages by checking
Trogon-Claim-Key headers, deletes objects with no matching claim. More complex but reclaims storage faster.
Recommended approach
- Set
max_age on the trogon-claims bucket config — this is the immediate fix
- Add
ObjectStoreDelete trait and have consumers delete after resolve — this handles the happy path
- Defer the reaper unless storage pressure becomes a real concern
ClaimCheckPublishercan leave orphaned objects if publish fails after a successful puttrogon-claimsbucket currently uses..Default::default()with nomax_age, so orphans accumulate foreverDesign considerations
Two cleanup paths are needed:
Happy path: consumer deletes after resolve
resolve_claimreads the object from the store. After successful resolution, the consumer should delete the object — that's the normal claim check lifecycle (put → publish claim → resolve → delete). This requires adding anObjectStoreDeletetrait and wiring it intoresolve_claimor letting the caller handle deletion after consuming the payload.Failure path: orphaned objects
When publish fails after a successful put, no claim message exists to reference the object. Options:
max_ageon the bucket (e.g. match stream's 7-day retention). Simple, predictable. Orphans expire automatically. Trade-off: storage cost for the TTL window.Trogon-Claim-Keyheaders, deletes objects with no matching claim. More complex but reclaims storage faster.Recommended approach
max_ageon thetrogon-claimsbucket config — this is the immediate fixObjectStoreDeletetrait and have consumers delete after resolve — this handles the happy path