Orphaned continuation chunks are never reclaimed, though three comments promise a database check will

[lvca]

Found while building the #6196 fixtures (PR #6287), and confirmed on main at a03af88.

What happens

Force-deleting a record with a broken chunk chain frees the HEAD slot only. Its continuation chunks are
orphaned - and nothing ever collects them. A bucket whose one 200 KB record was force-deleted by
CHECK DATABASE FIX:

before FIX:  totalMultiPageRecords=1  totalChunks=4  totalAllocatedRecords=11
after  FIX:  totalMultiPageRecords=0  totalChunks=4  totalAllocatedRecords=10

Four NEXT_CHUNK slots, each holding up to a page of content, reachable by nothing and reported as chunks of a
record that no longer exists. Repeated runs do not change it.

Why the documented answer is not the actual one

Three places in the tree tell the reader these get cleaned up later:

• deleteRecordInternal: "the chunks past this break are orphaned - a bounded space leak reclaimed by
  compaction or a later database check"
• check(): "any unreachable chunks are reclaimed later by compaction or a database check"
• deleteRecord(RID, boolean)'s javadoc: "orphaned (a bounded space leak) to be reclaimed by compaction or a
  database check"

Neither mechanism does it:

• check() counts a NEXT_CHUNK slot under totalChunks and moves on. There is no pass that walks the live
  chains to find which chunk slots nothing points at, and no orphanedChunks field beside the
  orphanedEdgeSegmentsReclaimed / orphanedExternalRecordsFixed the checker already reports for the OTHER two
  kinds of orphan it knows about.
• compressPage/getOrderedRecordsInPage re-flow a page's live slots; an orphaned chunk still has a live slot
  entry and a NEXT_CHUNK marker, so it is re-flowed along with everything else, never dropped.

The leak is bounded per incident but permanent, and it survives every repair an operator can run short of
exporting and reimporting the database.

Worth considering

Reclaiming a chunk requires knowing that no chain points at it, which is not answerable from the chunk's own
slot - the same asymmetry that makes #6196's content records need a marker. Two shapes fit the checker as it
already works:

1. Mark-and-sweep within the bucket, on the single pass check() already makes (Follow-ups from #5764: CHECK DATABASE materialises every record twice, two arms still say "removing it" when nothing is removed, and three smaller checker/test cleanups #5773): collect the
   continuation pointers of every chunk head it walks into a LongHashSet, and after the pass report - and with
   fix, free - every NEXT_CHUNK slot not in it. One set entry per chunk, on an operation that already reads
   every page and walks every chain. This is what orphanedEdgeSegments already does for edge segments, so it
   is a shape the checker and its result schema both already have.

2. Free them at the source: have the force-delete keep walking past the break rather than stopping, so the
   chunks it can still reach are freed instead of abandoned. Cheaper, but strictly weaker - it cannot reach
   chunks past a second break, or ones orphaned by the paths that leave chunks behind without deleting anything
   (GraphEngine.rebuildVertexEdgeChain, an interrupted updateMultiPageRecord shrink).

The two compose: (2) shrinks the population, (1) is what makes the claim in those three comments true. Until one
of them exists, those comments should say that the chunks leak.

[lvca]

Fixed by #6299 (merged as 0efa999), as option (1) - mark-and-sweep on the single pass check() already makes - and the marks cost nothing new: findBrokenChunkChain's loop-detector set already IS the set of chunks the walk went through, so it is handed back through a ChunkChainWalk instead of being thrown away.

Option (2) is deliberately NOT implemented. Past a break there is nothing trustworthy to follow, and a corrupted pointer would lead the free into unrelated slots. The effect it was after falls out of (1) for free: a head this run repaired away marks NOTHING, so its whole chain - including the chunks before the break - is swept by the same pass.

The three comments that promised compaction would reclaim these are corrected. compressPage re-flows a page's LIVE slots, and an orphaned chunk still has one.

Fails closed, like GraphDatabaseChecker's edge-segment reclaim: any gap in the marking (a page the walk could not read, a chain walk stopped by an I/O fault, a slot that could not be classified) disables the sweep entirely rather than shrinking it, and says so rather than reporting zero orphans. On review, findBrokenChunkChain's outer catch was brought into that rule too: it still reports a break, which is what check(fix) has always deleted the record on, but no longer claims the walk reached a conclusion - an exception is only as trustworthy as its cause, and freeing a chunk on that evidence is unrecoverable.

What the sweep found on its first real workload

CRUDTest.multiUpdatesOverlap (131072 records, thirteen rounds of updates) ends with 243821 orphaned chunks out of 1545495 - 16% of the bucket's chunk slots reachable from nothing. Verified real rather than assumed: every unmarked chunk was probed by scanning the whole bucket for a slot naming it, and they have either no referrer at all or a referrer that is itself unmarked (orphaned sub-chains). The leak has always been there; this is simply the first thing that can see it. Filed separately as a follow-up - the sweep reclaims it, but the update path that produces it is worth fixing at the source.

That scale also settled the reporting shape:

• An orphan is a COUNT, not an error and not a warning. Nothing is corrupted by one: no record is wrong, no query is affected, no two counts disagree. orphanedEdgeSegments and orphanedExternalRecords are both reported that way already, and one warning apiece here would have built a quarter of a million strings. Fields: orphanedChunks (found) and orphanedChunksReclaimed (freed).
• The reclaim is bounded by MEMORY, not by count. The enclosing transaction holds a copy of every page it modifies, so the cost is pages x pageSize whatever the backlog is. A run frees what fits a 32 MB page budget, reports the rest through the gap between the two counters, and the next FIX continues - so a bulk repair converges instead of ending as the OutOfMemoryError of fix: CHECK DATABASE causes Java heap space OOM (6GB heap) #4653.