Show how much longer a rate limited batch has to run

[alistair3149]

Follows-up to #89

A throttled row said only that it was waiting, so a batch that was working correctly but slowly looked the same as one that had hung. On a wiki allowing 8 uploads a minute, 100 files take over twelve minutes — the right outcome, but only if the user is told.

A line above the result list now says how much longer the wiki's limit will hold the batch up:

About 3 minutes left at this wiki's upload rate limit.

It is a schedule, not a measurement

The gate hands out one upload slot per interval and already knows when the next is due, so the figure is arithmetic on a schedule the client is itself enforcing:

remaining = waitMs + ( pending − 1 ) × intervalMs

Nothing is sampled, so nothing needs smoothing. The exponential averaging and downward bias that upload UIs usually carry exist to tame a measured byte rate; there is no byte rate here.

It excludes the transfer time itself, which is additive and matters for large files, and it can grow if the wiki refuses again. Hence "about", and hence whole minutes rather than a countdown.

Shown only while throttled

Pacing begins on the first refusal and lapses after a quiet window, so that is exactly when a schedule exists. Before then there is nothing to estimate — and inferring one from the advertised hits would assume a fresh budget, which is the one thing uiprop=ratelimits does not report. No placeholder, no "calculating…", and the line removes itself when the batch ends or the gate gives up.

Rows are untouched: a row still says why it is stuck, and one line says how long. Per-file figures would be invented, since slots are handed out in promise-resolution order and a retry takes a fresh one.

Rounding is the accessibility fix

The line is a role="status" live region and the DOM write is guarded on the text actually changing. Because it is whole minutes, the string changes at most once a minute. Verified against a live wiki: a 128 second batch produced two distinct strings, so two announcements rather than 128.

The count comes from the batch limit, not the queue

batchLimit.active() spans admit-to-terminal. queue.running() + queue.waiting() looks equivalent and is not: a file being retried has left the queue and not yet rejoined it, so the queue undercounts by one per retrying file at exactly the moment onRateLimited fires and the figure is refreshed.

Verified

95 unit tests; PHPCS, PHPStan and PHPUnit green. Checked in a browser at 2 uploads per 40 seconds: no line before the first refusal, "About 2 minutes left" then "Less than a minute left" during, and no line once all seven files had landed.

Considered, omitted

• A countdown, or any display of seconds. Seconds are the digit that forces a repaint and the least trustworthy part of the number.
• Per-file estimates or queue positions. Not knowable — see above.
• Measuring throughput to estimate unthrottled uploads too. That is a different and much weaker feature: it needs a sampled byte rate, and the answer would not be reliable.
• An hours unit. "About 90 minutes left" is fine and avoids a second rounding decision.
• A config variable to turn it off.

---

_{AI-authored — Claude Code, Opus 5 1M (ultracode); one-line ask, then one clarification confirming it should appear only while throttled; diff not yet human-reviewed; 95 unit tests plus PHPCS/PHPStan/PHPUnit green, and the readout checked end to end in a browser against a live wiki.}

[alistair3149]