Media upload: track upload progress with a per-session batch record instead of cumulative counters #82264

Follow up from the review discussion on #81397 - opening this so @andrewserong's batch record idea doesn't get lost (#81397 (review) and #81397 (comment)).

Claude gathered the thread into an issue, here is the write-up:

Current shape

The upload progress snackbar in @wordpress/editor is the only consumer of upload progress today, and it reads from two sources that both keep running tallies rather than per-batch records:

• For the traditional upload path, a minimal in-memory tracker (packages/editor/src/components/upload-progress-snackbar/tracker.js) holds a single { total, completed, pending } session. addFiles deliberately folds a new batch into the session already in progress - two blocks uploading at once produce one "Uploading 3 of 5" line instead of two competing snackbars - and advance clears the state the moment completed >= total. That clearing transition is exactly what the snackbar watches to know the queue drained.
• For the client-side processing path, Media: Stop claiming "Upload complete" when every upload failed #81397 has the snackbar snapshot a cumulative failure tally from @wordpress/upload-media (via a private getFailureCount selector) when a session starts, then subtract failuresAtStart at the end to work out how many failures belong to this session.

The subtraction fixes the "Upload complete" bug, but as noted in review, keeping a running total of all failures in the editor session and doing arithmetic against a snapshot signals the shape isn't quite right yet.

Proposal

Lean into the batch idea that already exists in places: a session record along the lines of { total, succeeded, failed } that both upload paths report into, with the consumer releasing the record when it is done with it (eg. when the snackbar closes).

Two design questions fall out of the current behavior:

• Overlapping batches are the reason the tracker folds everything into one session. A strictly per-batch record would leave the snackbar picking which batch to show, or merging them back together anyway - so the record probably stays session-scoped, with batches feeding into it.
• Lifecycle ownership is the more interesting half. Today the tracker clears itself when the count drains, and the snackbar treats that as the end signal. A record that lives long enough to report succeeded/failed needs the consumer to say when it is done, which moves lifecycle ownership from the tracker to the consumer. That is probably the right shape, but it is a behavior change rather than a bug fix, which is why it was split out of Media: Stop claiming "Upload complete" when every upload failed #81397.

Worth noting the client-side processing store already has some of the pieces: queue items carry a batchId, and there is a private isBatchUploaded selector. A shared record both paths report into would let both tallies stop being cumulative and remove the subtraction entirely.

Why now

With only one consumer this isn't causing problems, but it feels like the right thing to sort out before client-side media processing shows up anywhere beyond the editor - each new surface would otherwise reimplement the snapshot-and-subtract dance.

Questions

• Should the record be session-scoped (batches folded in, as today) or per-batch with the consumer aggregating?
• Who ends a session - the consumer explicitly, or a timeout/idle heuristic?
• Does the record belong in @wordpress/upload-media so both paths share it, and can the editor-local tracker then go away?

Related: #81397

cc: @andrewserong

AI Use

Description drafted with 🤖 Claude Code from the linked review discussion.