Dropping a table can leave orphan blobs on disk — blobs whose record references are no longer in any audit/active state but whose underlying files remain. Orphan-blob cleanup eventually removes them, but the gap between drop and cleanup is a leak.
Reproduction (from Jira)
Cluster of two nodes (ord01, ord02):
- Run a script that writes records containing blobs to
BlobHammerRun.
- Drop
BlobHammerRun on ord01.
- Wait for audit log to expire (without restarting Harper).
ord01 audit is null (table dropped); ord02 audit shows 1238 entries.
- After audit expires:
ord01 audit null, ord02 audit 2.
- Restart Harper on both nodes.
ord01 shows 528 orphan blobs (0 records, 2 audit entries); ord02 shows 752 blobs with 1233 records and 2 audit entries.
- Orphan-blob cleanup runs and deletes the 528 blobs from
ord01.
Log evidence:
[http/2] [warn]: Checking for references to potential orphaned blobs in table BlobHammerRun
[http/2] [warn]: Checking for references to potential orphaned blobs in the audit log
[http/2] [warn]: Deleting 528 orphaned blobs
[http/2] [warn]: Finished deleting 528 orphaned blobs
[http/2] [warn]: Cleaned Orphan Blobs from BlobTest, deleted 528 blobs)
Why this matters
The drop path should clean up the blobs it owns rather than leaving them for the orphan sweeper. Jira notes "we don't believe this has a production impact" — but it's the same root cause family as the broader orphan blobs investigation, and the gap could matter on a node with many drops in flight or a slow orphan sweeper.
Acceptance criteria
- Dropping a table eagerly deletes the blob files referenced only by records in that table (and only by audit entries that will not survive).
- The "wait for orphan sweep to find them" path remains as a safety net but is no longer the primary cleanup mechanism for drop-driven orphans.
Related
- CORE-3016 — Orphan blobs tracking & insights (lavinia's working notebook).
Tracked in Jira: CORE-3003
🤖 Filed by Claude on behalf of Kris.
Dropping a table can leave orphan blobs on disk — blobs whose record references are no longer in any audit/active state but whose underlying files remain. Orphan-blob cleanup eventually removes them, but the gap between drop and cleanup is a leak.
Reproduction (from Jira)
Cluster of two nodes (
ord01,ord02):BlobHammerRun.BlobHammerRunonord01.ord01audit is null (table dropped);ord02audit shows 1238 entries.ord01audit null,ord02audit 2.ord01shows 528 orphan blobs (0 records, 2 audit entries);ord02shows 752 blobs with 1233 records and 2 audit entries.ord01.Log evidence:
Why this matters
The drop path should clean up the blobs it owns rather than leaving them for the orphan sweeper. Jira notes "we don't believe this has a production impact" — but it's the same root cause family as the broader orphan blobs investigation, and the gap could matter on a node with many drops in flight or a slow orphan sweeper.
Acceptance criteria
Related
Tracked in Jira: CORE-3003
🤖 Filed by Claude on behalf of Kris.