Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700)

[philcunliffe]

Fixes#700.

What

The central server sorts each day's cache table in place right before its nightly export (hypaware-server LLP 0115/0116): an in-place replace snapshot committed through icebird, without touching the kernel's partition cursor. The LLP 0199 baseline gate only recognizes the kernel's own rewrites, so the foreign replace read as growth, the avg-file-size heuristic flagged the freshly sorted day, and the next hourly maintenance tick rewrote it back into ~0.5MB per-batch files 30-90 minutes after export - every night, for every exported day (prod timeline in #700).

The due-test now recognizes the foreign rewrite: when a compaction-due partition's current snapshot is a replace committed under the table's declared default sort order (the kernel-side mirror of the server day compactor's alreadyCompacted + sortOrderDeclared skip), and no append has landed since (the replace still being current is exactly that test), maintenance records the live data-file count as the new cursor baseline and skips the rewrite. Documented as LLP 0207, extending LLP 0199.

Design points

• Single metadata load. The metadata read the recognition needs is the one compactGeneration already did for schema/spec/sort-order carry; it is hoisted into loadCompactionTableInfo and shared, loaded once per compaction-due partition. Partitions not due still pay nothing.
• Recognition outranks the re-settle force. The LLP 0027 sweep only runs inside a rewrite; letting it override would mean one leftover unmatchable fallback row re-shreds the sorted layout every night. Settlement of fallback rows under a foreign sorted replace defers to the next append (LLP 0207#outranks-resettle states the trade).
• Arbitrary replaces are not blessed. A replace on a table with no declared sort order stays due, and an explicit --force still rewrites.
• A late append is unchanged behavior: it flips the current snapshot's operation off replace and moves the count off the baseline, so the partition is genuinely due again.
• Reports gain a rebaselined flag (mutually exclusive with compacted); dry runs predict the recognition without writing the cursor.

Tests

Three new cases in test/core/cache-retention-maintenance.test.js (fixture style of the LLP 0199 tests, foreign rewrite simulated with icebird's icebergRewrite, the same call the server makes):

1. sorted replace + baseline mismatch: no rewrite, cursor re-baselined to the live count, compactedAt preserved, converged on the next tick, due again after a late append
2. replace without a declared sort order: still rewritten
3. --force: still rewritten

Full suite: 3889 pass / 1 pre-existing failure (leave-command#623 case, fails identically on master). Typecheck green.

Coordination

Sibling of #697 / PR #698 (same file, same walk): #698 changes how the kernel's own rewrites size files; this PR stops the kernel destroying the server's rewrites. Kept deliberately independent per #700; the overlap is small (compactGeneration head, types.d.ts, an Extended-by line both PRs add to LLP 0199) and rebases cleanly whichever lands first.

Prod verification (after release + server image rebuild)

After the next 01:00Z export tick, the just-exported day's cache partition should keep its sorted form: cursor epoch unchanged, compaction.resettleBaselineFiles moved to the small live count, no epoch bump 30-90 min post-export, file count stays small. Payoff claim to verify: the whole 7-day cache window serves the sorted layout within a week of shipping.

🤖 Generated with Claude Code

[philcunliffe]

Dual-agent review — request_changes (round 1)

• Verdict:request_changes
• Risk class:medium
• Auto-merge advisory: 👎 thumbs down — verdict is request_changes; needs human-gated follow-up

Advisory only: no merge was attempted. All findings are minors; fixes and a full round 2 follow on this PR.

Risk capstone

Cross-reference: reviewer findings vs high-risk surfaces

Source	Finding (severity, evidence)	Intersects
Claude	Pre-replace data files leak until eviction (minor, maintenance.js:296-300)	Risks bullet 1
Claude	Rebaseline invisible in hyp query maintain (minor, query.js:322)	Direct callers (CLI printer)
Codex	Same CLI/operability gap (minor, cat 11, query.js:317-327)	Direct callers (CLI printer)
Claude	Source-table layout untested on rebaseline path (minor, test:833)	Risks bullet 2
Claude	Outranks-resettle precedence untested (minor, maintenance.js:296)	Risks bullet 2

Codex review

Fix Validations

Foreign sorted replace was treated as growth and rewritten

• Status: correct
• Evidence:src/core/cache/maintenance.js:273, src/core/cache/maintenance.js:285, src/core/cache/maintenance.js:296, src/core/cache/maintenance.js:299, src/core/cache/maintenance.js:480
• Assessment: The new path runs only after the existing due-test says compaction would happen, recognizes current replace snapshots on sorted tables, writes only the baseline cursor, and skips compactGeneration.

Existing handling could not already fix this

• Status: correct
• Evidence:src/core/cache/maintenance.js:273, src/core/cache/maintenance.js:285
• Assessment: The prior gate only compared live data-file count to resettleBaselineFiles; a foreign rewrite that changed the count still flowed into shouldCompact.

Unsorted replace and explicit force still rewrite

• Status: correct
• Evidence:src/core/cache/maintenance.js:296, src/core/cache/maintenance.js:481, test/core/cache-retention-maintenance.test.js:891, test/core/cache-retention-maintenance.test.js:913
• Assessment:--force bypasses recognition, and tables without declared sort columns fail foreignSortedReplace.

Findings

11) Debuggability & Operability

• Severity: minor
• Confidence: high
• Evidence:src/core/cache/maintenance.js:297, src/core/cache/maintenance.js:299, src/core/commands/query.js:317, src/core/commands/query.js:321, src/core/commands/query.js:327
• Why it matters:hyp query maintain can now perform or dry-run a meaningful cursor rebaseline, but the CLI prints no per-partition action and the summary still reports only compacted partitions, making prod verification of this fix look like “nothing happened.”
• Suggested fix: Teach the CLI formatter to include p.rebaselined, for example rebaselined to N files, and consider adding a total rebaseline count to the human summary.

No Finding

1. Behavioral Correctness
2. Contract & Interface Fidelity
3. Change Impact / Blast Radius
4. Concurrency, Ordering & State Safety
5. Error Handling & Resilience
6. Security Surface
7. Resource Lifecycle & Cleanup
8. Release Safety
9. Test Evidence Quality
10. Architectural Consistency

Evidence Bundle

• Changed hot paths:maintainCache report aggregation, maintainGeneration compaction due path, loadCompactionTableInfo, foreignSortedReplace, compactGeneration, cursor baseline handling.
• Impacted callers:src/core/commands/query.js:301, src/core/commands/query.js:317, src/core/daemon/runtime.js:672, hypaware-core/smoke/flows/cache_lifecycle_maintenance.js:98.
• Impacted tests:test/core/cache-retention-maintenance.test.js:833, test/core/cache-retention-maintenance.test.js:891, test/core/cache-retention-maintenance.test.js:913, existing baseline test at test/core/cache-retention-maintenance.test.js:783.
• Unresolved uncertainty: I did not rerun the suite; review is based on the provided diff plus targeted caller/contract tracing.

Claude review

Claude review

Re-baseline permanently leaks the pre-replace data files (disk ~2x per exported day)

• Severity: minor
• Confidence: 85
• Evidence: src/core/cache/maintenance.js:296-300
• Why it matters: The foreign replace leaves the old per-batch parquet files on disk in the same generation dir (icebird's icebergExpireSnapshots documents that expiry never deletes data files, and walkForRetired only reclaims non-live generation dirs); before this PR the nightly kernel rewrite incidentally reclaimed them by retiring the whole generation, but the new re-baseline keeps that generation live, so every exported day's partition holds both the shredded and the sorted file sets (~2x data) until cache eviction, with no code path that deletes the unreferenced files.
• Suggested fix: Record the trade explicitly in LLP 0207's Consequences with a follow-up issue for unreferenced-file GC (or delete files unreferenced by the current snapshot's manifests once expiry ages out the pre-replace snapshots).

Rebaseline is invisible in hyp query maintain output

• Severity: minor
• Confidence: 85
• Evidence: src/core/commands/query.js:322
• Why it matters: The CLI's per-partition line only prints snapshotsExpired/compacted actions and the summary only counts totalCompacted, so a run that recognizes a foreign replace and writes a cursor (or a --dry-run predicting it) prints nothing for that partition and reads as "nothing due", hiding a state-mutating action; there is also no metric counterpart to compactionsCounter.
• Suggested fix: Push an action such as rebaselined to N files (foreign sorted replace) when p.rebaselined is set, and consider a maintenance.rebaselines counter so prod verification does not require reading cursor JSON by hand.

Foreign-replace recognition untested on the source-table layout

• Severity: minor
• Confidence: 82
• Evidence: test/core/cache-retention-maintenance.test.js:833
• Why it matters: All three LLP 0207 tests write layout: 'epoch' cursors, but the server's day compactor commits foreign replaces onto both layouts in prod, and the layout-varying pieces the recognition depends on (liveDir = cursor.tableDir ?? 'table' resolution, rebaselineCursor's spread preserving tableDir/retention) never run under the rebaseline path.
• Suggested fix: Add one source-table variant of the recognition test asserting rebaselined, cursor tableDir unchanged, and resettleBaselineFiles moved.

Recognition-outranks-resettle decision has no test

• Severity: minor
• Confidence: 80
• Evidence: src/core/cache/maintenance.js:296
• Why it matters: The PR names "recognition outranks the re-settle force" as a design point and mints LLP 0207#outranks-resettle for it (the exact nightly re-shred recurrence the fix exists to stop), but no test threads a settle context plus a resettle candidate under a foreign sorted replace; a future edit adding !hasResettle to the guard would silently regress.
• Suggested fix: Add a case with a committed fallback row + foreign sorted replace + settle context, asserting rebaselined true and no rewrite.

---

Reports: /Users/phil/workspace/hypaware/.git/worktrees/issue-700/dual-review/pr-701

[philcunliffe]

Dual-agent review — approve (round 2, full re-review after round 1 fixes)

• Verdict:approve
• Risk class:low
• Auto-merge advisory: 👍 thumbs up — approve verdict, low blast radius, both reviewer artifacts present, no blocker/major findings

Advisory only: no merge was attempted.

All four round 1 minors are addressed in 287b67b: disk trade documented in LLP 0207 and tracked as #704; rebaselines visible in hyp query maintain output and as a hyp_rebaselines metric; source-table layout and recognition-outranks-resettle now tested.

Risk capstone

Cross-reference: reviewer findings vs high-risk surfaces

Source	Finding (severity, evidence)	Intersects
(none)	(none)	(none)

Codex review

Fix Validations

Foreign sorted replace was being re-compacted after export

• Status: correct
• Evidence:src/core/cache/maintenance.js:277, src/core/cache/maintenance.js:289, src/core/cache/maintenance.js:300, src/core/cache/maintenance.js:303, src/core/cache/maintenance.js:485, src/core/cache/maintenance.js:491, test/core/cache-retention-maintenance.test.js:833
• Assessment: The existing baseline gate only handled equal file counts. The new branch recognizes a current replace snapshot on a table with declared sort columns, writes the live count into the cursor, and skips the rewrite.

Re-settle force must not shred a recognized sorted replace

• Status: correct
• Evidence:src/core/cache/maintenance.js:286, src/core/cache/maintenance.js:289, src/core/cache/maintenance.js:300, test/core/cache-retention-maintenance.test.js:927
• Assessment:hasResettle can make the partition due, but the foreign-replace branch outranks it unless --force is set. The test asserts the sweep hook is not reached.

Unsorted replace and explicit force stay rewrite paths

• Status: correct
• Evidence:src/core/cache/maintenance.js:300, src/core/cache/maintenance.js:486, test/core/cache-retention-maintenance.test.js:960, test/core/cache-retention-maintenance.test.js:982
• Assessment: No declared sort order returns false, and opts.force bypasses recognition. Both edge cases are covered.

Findings

No new findings.

No Finding

1. Behavioral Correctness
2. Contract & Interface Fidelity
3. Change Impact / Blast Radius
4. Concurrency, Ordering & State Safety
5. Error Handling & Resilience
6. Security Surface
7. Resource Lifecycle & Cleanup
8. Release Safety
9. Test Evidence Quality
10. Architectural Consistency
11. Debuggability & Operability

Evidence Bundle

• Changed hot paths:maintainCache partition loop src/core/cache/maintenance.js:91; compaction due-test src/core/cache/maintenance.js:252; foreign replace recognition src/core/cache/maintenance.js:485; compaction metadata carry src/core/cache/maintenance.js:563; CLI reporting src/core/commands/query.js:317.
• Impacted callers: daemon maintenance src/core/daemon/runtime.js:672; manual CLI maintain src/core/commands/query.js:301; cache lifecycle smoke hypaware-core/smoke/flows/cache_lifecycle_maintenance.js:98; incremental sink compaction smoke hypaware-core/smoke/flows/incremental_sink_compaction.js:157.
• Impacted tests: existing baseline convergence test/core/cache-retention-maintenance.test.js:783; new sorted replace case test/core/cache-retention-maintenance.test.js:833; source-table layout test/core/cache-retention-maintenance.test.js:891; re-settle precedence test/core/cache-retention-maintenance.test.js:927; unsorted replace test/core/cache-retention-maintenance.test.js:960; force override test/core/cache-retention-maintenance.test.js:982.
• Unresolved uncertainty: I did not inspect server-side LLP 0115/0116, so I validated the kernel-side recognition against this PR’s stated Icebird replace shape. Test run: npm test -- test/core/cache-retention-maintenance.test.js exercised the suite; LLP 0207 tests passed, with the known pre-existing leave-commandLLP 0063 D4 exclusivity gate fails open on an unparseable central layer: login to a second org is permitted while enrolled #623 failure still failing.

Claude review

Claude review

No issues found.

Round 2 (two independent reviewers, full fresh pass over the complete diff including the round 1 fix commit). Verified: rebaselinesCounter threading and real-run-only increment; the printed rebaseline count equals the value written to the cursor (asserted by test); no consumer parses the changed maintenance: summary format (the smoke flow's totalCompacted check runs under force, which bypasses recognition); the outranks-resettle test is not vacuous (recognition asserted via rebaselined/epoch/totalCompacted independently of the throwing-hook tripwire, and resolveSettleContext genuinely resolves for the fixture); all @ref anchors resolve and the LLP 0207 consequences (dry-run behavior, 2x-disk trade, single metadata load) match the code; guidance clean (no semicolons, no em dashes, JSDoc/@ref conventions followed).

All four round 1 findings confirmed addressed: disk trade documented in LLP 0207 + tracked as #704; rebaseline visible in hyp query maintain output and as a hyp_rebaselines metric; source-table layout covered; recognition-outranks-resettle covered.

---

Reports: /Users/phil/workspace/hypaware/.git/worktrees/issue-700/dual-review/pr-701

[philcunliffe]

🧭 Decision map — where to spend your attention

Companion to the dual-review verdict. This casts no verdict — it points at the 5 forks where the author made a real choice, so you can skim the rest.

Scanned: 13 hunks across 6 files. Most is mechanical: the metadata-load hoist into loadCompactionTableInfo and its parameter threading, the rebaselined report field, CLI printer lines, and ~200 lines of test fixtures. The decisions worth your eyes, in order:

1. A declared default sort order is the deliberateness signal · contract / shape

src/core/cache/maintenance.js:486

functionforeignSortedReplace(tableInfo){if(!tableInfo?.sortColumns?.length)returnfalse

• Decision: only a replace on a table whose default sort order is declared (identity transforms) earns convergence credit; the columns and directions themselves are not checked.
• Alternative not taken: bless any current replace (risks crediting arbitrary foreign rewrites with worse layouts), or pin the exact server sort columns (couples the kernel to a column list the server owns and may evolve).
• Check: the server's day compactor always declares the order before rewriting (declareSortOrder in hypaware-server's day-compaction.js), so recognition actually fires in prod; this cross-repo convention is the whole contract.

2. Recognition outranks the re-settle force · unhappy-path policy

src/core/cache/maintenance.js:300

if(!opts.force&&foreignSortedReplace(tableInfo)){

• Decision: a partition due only because it holds committed fallback rows (LLP 0027 sweep trigger) is still skipped under a foreign sorted replace; settlement defers to the next append, indefinitely for closed days.
• Alternative not taken: let the sweep force the rewrite — which re-shreds the sorted layout every night whenever one unmatchable fallback row exists, reproducing the exact bug being fixed.
• Check: that indefinitely-provisional fallback rows on closed days are an acceptable cost (LLP 0207#outranks-resettle states the trade).

3. replace-is-current doubles as the no-append-since test · algorithm

src/core/cache/maintenance.js:491

returnsnapshot?.summary?.operation==='replace'

• Decision: "nothing appended since the sorted rewrite" is inferred entirely from the current snapshot's operation still being replace.
• Alternative not taken: compare snapshot timestamps or track append counts in the cursor — more state, and the operation check is exactly what the server's own alreadyCompacted skip relies on.
• Check: every write that should re-open the partition flips the current operation (mover appends commit append, retention commits deletes); a hypothetical future writer committing replace would be silently blessed only if it also declares the sort order.

4. Re-baseline moves only the baseline; compactedAt and the epoch stay · contract / shape

src/core/cache/maintenance.js:872

return{ ...cursor,compaction: { ...compaction,resettleBaselineFiles: liveDataFiles}}

• Decision: the recognition write is deliberately not a compaction record: no epoch bump, no compactedAt restamp, everything else spread through.
• Alternative not taken: stamp a rebaselinedAt/refresh compactedAt (would make prod cursors indistinguishable from a kernel rewrite, the exact signal the Maintenance compaction shreds the export-time sorted rewrite: due-test is blind to foreign replace snapshots #700 verification depends on) or bump the epoch (would retire a generation that was never replaced).
• Check: no consumer assumes resettleBaselineFiles and compactedAt were written by the same run.

5. Pre-replace data files are left on disk until eviction · lifecycle

llp/0207-foreign-sorted-replace-convergence.decision.md:70

- The pre-replace data files stay on disk until day eviction: snapshot
expiry never deletes data files, and the orphan sweep only reclaims
non-live generation dirs, so a recognized partition holds both file

• Decision: accept ~2x disk per exported day for the cache window; reclamation is deferred to Cache maintenance never reclaims data files unreferenced by the current snapshot inside a live generation #704 rather than done at recognition time.
• Alternative not taken: delete unreferenced files inside the live generation during recognition — cheaper on disk but a new, riskier deletion path racing in-flight readers, in the same PR as a behavior fix.
• Check: prod disk headroom tolerates the window (the shredding rewrite previously masked this by retiring whole generations nightly).

---

Honorable mentions (real but lower-stakes): src/core/cache/maintenance.js:296 — --force bypasses recognition entirely (operator override wins); src/core/commands/query.js:325 — the CLI prints dataFilesBefore as the rebaseline count, which is exactly the value written to the cursor; src/core/cache/maintenance.js:102 — a new hyp_rebaselines counter rather than overloading hyp_compactions.

_{Generated by /decision-map. Advisory — directs attention, casts no verdict.}

[philcunliffe]

Review round 1 - head 287b67b

Verdict: approve. The recognition predicate is sound, the baseline bookkeeping cannot reintroduce the LLP 0199 loop, the single-metadata-load claim holds, the LLP edit is a clean forward-ref, and the tests build a real foreign replace via icebergRewrite. Four improvements were raised and all four are fixed in cc82d6f. Gates: npm test 3893 pass / 0 fail, npm run typecheck clean, smokes cache_lifecycle_maintenance / incremental_sink_compaction / cache_roundtrip ok, no em dashes, no semicolons.

False-positive enumeration (the main ask)

Every writer that could put a replace at the head of a cache table was traced:

• The kernel's own rewrite cannot false-positive.compactGeneration writes into a fresh generation directory via appendRowsToTable, so the new live table's current snapshot is always append. The only replace producer in icebird is write/rewrite.js:220, and its only in-repo caller is src/core/commands/sink.js (export sink tables, not the cache datasets tree).
• Retention deletes cannot false-positive - they use position-deletes (operation: 'delete'), flipping the current operation away from replace.
• Snapshot expiry is safe - expireSnapshots explicitly skips the current id, so the replace stays current and stays recognized.
• A table with no declared sort order is correctly not blessed.sortColumnsFromMetadata reads default-sort-order-id, which is only ever set at icebergCreateTable time; ordinary local ingest never declares one, so on a plain HypAware install foreignSortedReplace is unreachable by construction. This is the strongest part of the guard and it is directly tested.
• Partial/aborted replace is not reachable as current - icebird commits metadata atomically, so a crash leaves orphan parquet with the prior metadata current.
• A snapshot id missing from metadata.snapshots yields undefined, predicate false, compaction proceeds. Fails safe.

False-negative direction: the only miss is a replace followed by an append before the tick, which then rewrites. That is exactly the documented "no append since" semantics, correct for a still-live partition, and covered by the third leg of the first test.

The 0199 loop cannot return

rebaselineCursor moves only compaction.resettleBaselineFiles; epoch, rowCount, layout, tableDir, retention and compactedAt are preserved, with an isPlainObject guard against a garbage compaction. On the next tick dataFilesBefore === resettleBaselineFiles, so grewSinceCompaction is false and the partition drops out before any metadata load, while both append paths carry cursor.compaction through unchanged so a later append re-arms it. No path re-arms recognition against itself.

src/core/commands/query.js is germane, not scope creep: 7 lines of rendering, without which a rebaseline run prints nothing for the partition and reads as "nothing due".

Findings

1. minor - the predicate does not verify the replace was written under the declared sort order. It tests two independent facts (the table declares a non-empty default sort order now, and the current snapshot is a replace), never that this replace was committed under that order. icebird stamps sort_order_id per data file, so a replace written under order 0 on a table declaring order 1 would still be blessed. Not reachable from anything in this repo today, and LLP 0207 #foreign-replace states the two-fact test as the decision, so this is a documented narrowing rather than a defect. Deliberately not changed: tightening it costs a manifest read and would break the single-metadata-load property, so it belongs in a separate decision, not a drive-by.

2. minor - a full projected scan whose result was unconditionally discarded.hasResettleCandidate was computed before the recognition test, but recognition outranks it, so on the first tick after each foreign replace a partition with no fallback row paid a complete single-column scan of the day purely to throw the answer away.
Fixed: a cheap compactionDue check is hoisted above the scan and the scan is gated on !compactionDue && settle, with shouldCompact = compactionDue || hasResettle algebraically identical to before. Verified empirically rather than by reasoning: instrumenting hasResettleCandidate gives zero calls across the 36 retention/maintenance tests including every LLP 0207 recognition test, and still 4 calls in cache-resettle-sweep.test.js where the fallback-row scan is the only possible trigger. Instrumentation reverted before commit.

3. nit - Extended-by: lacked the corpus's explanatory gloss (a bare **Extended-by:** LLP 0207, where 0012/0017/0036/0041/0191 all carry a parenthetical and several link the target). Fixed to a linked, glossed form.

4. nit - MaintenanceReport gained no totalRebaselined, so query.js re-derived the count by filtering report.partitions, asymmetric with totalCompacted. Fixed: the aggregate is now on the report and read directly.

5. nit - the maintenance.partition span recorded nothing about a rebaseline, leaving the hyp_rebaselines counter as the only in-daemon signal. Fixed with a single additive span.setAttribute('rebaselined', ...), kept minimal to ease the #698 merge.

Cross-PR flag for whoever merges: #698 (fix/issue-697)

The two are complementary and compose correctly, but three things matter:

1. Neither obsoletes the other.Cache compaction sizes files by bytes written, not the in-memory batch estimate #698 fixes the consequence (the rewrite produced ~0.5MB files because the file boundary followed the in-memory batch estimate). Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700) #701 fixes the trigger (do not rewrite a foreign sorted day at all). Even with Cache compaction sizes files by bytes written, not the in-memory batch estimate #698, a kernel rewrite of an exported day would destroy the server's global session sort order (the kernel re-declares the sort order on the new table but writes rows in scan order, never re-sorting) and would still burn a full-partition rewrite plus doubled disk. Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700) #701 remains necessary after Cache compaction sizes files by bytes written, not the in-memory batch estimate #698.
2. Cache compaction sizes files by bytes written, not the in-memory batch estimate #698 cannot false-positive Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700) #701's predicate - its streaming sink still writes into the fresh generation directory via append-shaped commits, so a Cache compaction sizes files by bytes written, not the in-memory batch estimate #698-written generation's current snapshot is still append.
3. Textual overlap is at two hot spots and the merge is easy to get wrong. Both rewrite the if (shouldCompact) block in maintainGeneration and compactGeneration's preamble (Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700) #701removes the in-function metadata load and takes tableInfo as a parameter; Cache compaction sizes files by bytes written, not the in-memory batch estimate #698 wraps the body in try/finally and leaves the load in place). A resolution that takes Cache compaction sizes files by bytes written, not the in-memory batch estimate #698's compactGeneration wholesale would silently drop Maintenance recognizes a foreign sorted replace and re-baselines instead of shredding it (#700) #701's tableInfo parameter and reintroduce a second metadata load per compaction. Do not resolve either hunk by "take theirs".

Low priority: once both land, LLP 0207 #context justifies itself partly by the ~0.5MB-files harm that LLP 0208 (#698's renumbered doc) independently fixes, so the standing harm becomes "loses the global session sort, burns a pointless full rewrite, doubles disk". Worth a one-line Related: cross-ref when #698 lands.

The head moved to cc82d6f, so the next tick reviews it as round 2.