Documentation / @etherfold/browser / DEFAULT_PRUNE_BUDGET
Variable: DEFAULT_PRUNE_BUDGET ​
constDEFAULT_PRUNE_BUDGET:1000=1000
Defined in: packages/browser/src/IndexerState.ts:134
How many versions ONE scheduled prune may delete, where the application names no budget of its own.
A prune costs time proportional to what it DROPS, which is the whole reason ADR-0022 makes it a call the host schedules rather than something applyBlock does on its way past -- so a host that schedules one still has to decide how much of the backlog a single cycle pays for. This is that decision for a BROWSER TAB, and the axis it is chosen on is responsiveness rather than any cap a platform imposes (a Worker has one, and d1PruneBudget computes it; a tab does not).
The number: the IndexedDB prototype's FULL-SCAN prune took 6.3 s at 62,553 versions (work/notes/findings/sqlite-in-the-browser.md), so ~0.3 ms per version is a safe over-estimate for the shipped store, which walks an index instead. A thousand versions is therefore a fraction of a second of database work against an auto-index loop that rests at four seconds, and it drains the whole measured workload's unbounded footprint (29,393 versions) in about thirty cycles rather than in one long stall. A steady-state cycle deletes a handful and never reaches it.
It bounds ONE PASS and never the total: an incomplete pass leaves the rest for the next cycle, which is what keeps a large backlog off any single one.