What happens. The ledger fill reads each held account's repository page by page and stops only when a page is empty, a record is older than the oldest week kept, or the server sends no cursor. A server that always sends a cursor with more records from this week keeps that one account's read going forever. Every other account waits behind it, and the ledgers and the burn store take in every record it sends.
How to reproduce. fill.rs:151-177 loops on feed_page, which takes the server's cursor and every record in listing.records as given (feed.rs:324-334). There is no cap on pages or records per account. Each record goes to view.fill_line and shared.burn.put (fill.rs:166-170), and fill::run reads accounts one after another (fill.rs:102-115, 183-196). Any bot-labelled account whose DID document names a server its owner runs can answer listRecords like this. A local test with a stub HttpGet that answers every page with 100 new rkeys dated this week and cursor: c<n+1>, run under fill(.., Duration::ZERO, ..) with a 5 s timeout, read 197 pages and held 19,700 ledger lines without returning. At the production PACE of 250 ms that is about 400 records a second. A server that only repeats its cursor stalls the fill the same way without growing anything.
Why it matters. One account outside our control stops every other account from ever being counted into the weekly ledgers and burn. With fresh rkeys it also grows the open week's ledger rows, burn's windows and burn.json.journal until the index hits its 640 MB limit. Each insert also does a linear rkey scan under the view lock (tally.rs:377), which slows ingest as the ledger grows.
Fixed by https://tangled.org/permadeath.com/vibescrobble.com/pulls/341, now on main.