Background
#7567 lands per-pad and per-instance compaction (compactPad API + bin/compactPad + bin/compactAllPads). Both knobs operate on every targeted pad — there's no way to say "only compact pads that haven't been edited in a while."
For long-lived instances with a mix of hot and cold pads, that's the next missing piece. Compacting a recently-active pad is mostly wasted work — the history is what users are still navigating in timeslider. Compacting pads that haven't been touched in months is where the real reclaim is.
Proposal
Stay out of the API surface — staleness is a targeting concern, not a compaction concern. Two complementary surfaces:
1. bin/compactStalePads.ts (operator-on-demand)
node bin/compactStalePads.js --older-than 90 # collapse all history on pads
# not edited in the last 90 days
node bin/compactStalePads.js --older-than 90 --keep 50 # keep last 50 revisions
node bin/compactStalePads.js --older-than 90 --dry-run # list, don't write
Composition: listAllPads → for each, getLastEdited → filter by age → compactPad. Mirrors bin/compactAllPads.ts and reuses the same progress / error-tolerance shape.
2. cleanup.compactOlderThanDays setting (turn-it-on-and-forget)
Optional integer in settings.json. When set, runs the same loop on a daily timer (lines up with the existing cleanup.enabled story). Off by default.
Out of scope for this issue
- Adding staleness as a
compactPad API param. Targeting which pads is a different concern from how to compact one — keeping them separate keeps both simple.
- Non-time staleness signals (revision count thresholds, byte-size thresholds). Easy follow-ons once the day-based filter is in.
Acceptance
Background
#7567 lands per-pad and per-instance compaction (
compactPadAPI +bin/compactPad+bin/compactAllPads). Both knobs operate on every targeted pad — there's no way to say "only compact pads that haven't been edited in a while."For long-lived instances with a mix of hot and cold pads, that's the next missing piece. Compacting a recently-active pad is mostly wasted work — the history is what users are still navigating in timeslider. Compacting pads that haven't been touched in months is where the real reclaim is.
Proposal
Stay out of the API surface — staleness is a targeting concern, not a compaction concern. Two complementary surfaces:
1.
bin/compactStalePads.ts(operator-on-demand)Composition:
listAllPads→ for each,getLastEdited→ filter by age →compactPad. Mirrorsbin/compactAllPads.tsand reuses the same progress / error-tolerance shape.2.
cleanup.compactOlderThanDayssetting (turn-it-on-and-forget)Optional integer in
settings.json. When set, runs the same loop on a daily timer (lines up with the existingcleanup.enabledstory). Off by default.Out of scope for this issue
compactPadAPI param. Targeting which pads is a different concern from how to compact one — keeping them separate keeps both simple.Acceptance
bin/compactStalePads.tslands with--older-than,--keep,--dry-run