Compressatorium 4.4.2
Released 2026-08-16. The finished-job count stops lying at 500.
4.4.1 stopped a deep queue from deleting your job history. This one stops the
retention cap from lying about it. Same cap, same batches, the other half of
the problem: with 1,153 files queued, the Jobs panel sat at Completed 500
while the queue kept draining — and stayed there, however many finished.
It reads like a pagination bug. It isn't. 500 is MAX_JOB_HISTORY, the number
of finished jobs the backend keeps; the page size is 50 and had nothing to do
with it. Every finished-job count in the UI was derived from the list of jobs
still held, and that list is capped by deletion — so no count taken from it
could ever exceed the cap, no matter how much work finished.
The short version
- Completed and Failed now count every finished job, not just the ones still
retained — the dashboard's Done / Failed tiles too. - The tabs say when the list is shorter than the count: "Showing the 500
most recent of 1,153." Those older rows are gone, not on another page. - A tab whose jobs have all aged out says so, instead of "No completed jobs
yet" sitting under a non-zero badge. - Clear reports what it actually cleared — 1,153, not the 500 it could see.
Show metadata jobsstill applies to the totals, so pruned background
scans don't inflate a badge while their rows stay hidden.- New:
GET /api/jobs/history-overflowand ahistoryevent on
/api/jobs/events, for anything counting jobs through the API. - Queue counts were never affected. Pruning only ever touches finished jobs.
What you'll see
The badges are now retained + evicted — the real total for the run. Because
the evicted rows are genuinely deleted rather than paginated away, the panel
says so rather than letting the badge and the pager disagree in silence:
Showing the 500 most recent of 1,153. Older finished jobs are dropped once
history passes 500 (raiseMAX_JOB_HISTORYto keep more).
And when every retained slot has been taken by newer finished jobs, the tab
reports that instead of claiming there's nothing there:
Completed jobs aged out of history — These 1,153 finished, but history
keeps only the 500 most recent finished jobs and newer ones took every slot.
Clear is honest about its own scale. Past the cap it counted only the rows
it could still see, so clearing a 1,153-job run confirmed "Remove 1,153?" and
then reported "Removed 500." It now reports the full number, and still zeroes
everything — the evicted tally included, so a badge can never outlive the list
it came from.
Hidden work stays hidden. The tally is keyed by mode as well as status, so
pruned metadata_scan and dat_match history can't pad a badge while its rows
are filtered out. Jobs you dismiss by hand are never counted as evicted either:
that's history you dropped, not history the cap took.
For anything scripting the API
/api/jobs can only ever return what is retained, so a script counting
finished jobs from it hits the same ceiling the UI did. Two additive surfaces
fix that:
GET /api/jobs/history-overflow— how many finished jobs the cap has
evicted, broken down by status and mode, alongsidemax_job_historyitself.- A
historyevent on/api/jobs/events— the same totals, pushed on
connect and whenever they change. A client that doesn't listen for it drops it
silently, exactly as it doessnapshot.
Reading both halves at once is racy on its own, so the endpoint takes a cursor:
since (a sequence from a previous reply) plus generation (the backend
process that minted it). The reply names the jobs evicted since that point, so a
client can drop rows the cap deleted between its two reads instead of counting
them twice — once as a row, once in the tally. cursor_expired says the reply
can't be complete and the job list should be re-read. The full contract, and the
invariants a client has to preserve, are in
docs/DESIGN_tool_plugin_architecture.md §3.3.7.
Upgrade notes
No database migration. The schema is unchanged from 4.2.0 (0003 remains
the head).
No new settings. No environment variables were added, removed, or renamed.
MAX_JOB_HISTORY still means what it meant in 4.4.1 — how many finished
jobs are kept. What changed is that the counts no longer pretend that's the
same as how many finished. If you raised it purely to make the numbers look
right, you can put it back; raise it only if you want more of that history
browsable, and note the cost is memory, roughly linear in jobs retained.
API additions are backwards compatible. No existing endpoint, mode string,
or JSON shape changed. The history SSE event and the history-overflow
endpoint are new; older clients that ignore them behave exactly as before.
The image is unchanged in size. No new binaries or runtimes ship with this
release.
Nothing new is stored in your browser. The counting state is in-memory and
re-derived from the backend on every connect.