Details
- Create the blob using e.g. C++ service, or in any other way.
- Remove the blob using Rust implementation
- Ensure it is deleted in DynamoDB (both tables) and S3
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/blob/src/service.rs | ||
|---|---|---|
| 146–186 ↗ | (On Diff #18814) | If deleting reverse index is successful but then deleting the item fails, we would end up in a state where retrying will always fail. This isn't too serious, as we're planning to introduce proper cleanup procedure later, but maybe we should consider making it safer now.
The current solution matches what we already have, so maybe it is a good idea to create a followup task for handling deleting in a safer manner. |
| services/blob/src/service.rs | ||
|---|---|---|
| 146–186 ↗ | (On Diff #18814) | I think we can introduce a “nanny task” later that checks periodically for “orphaned” items and removes them |
| services/blob/src/service.rs | ||
|---|---|---|
| 146–186 ↗ | (On Diff #18814) | I admit that this code is problematic as failure anywhere results in an invalid state - tables will go out of sync. IMO removing reverse-index first is the best solution for now, because it makes it inaccessible anymore, even when further deletion (s3 or blob table) goes wrong.
+1 on this, I think it's more related to ENG-414 |