MR: https://gitlab.wikimedia.org/daanvr/upload-workbench/-/merge_requests/29
Preview: https://upload-workbench.toolforge.org/mr-29/

At first sight it seems to work, however, when playing with it a bit uh it seems a bit buggy. When I select restore all for the hidden uh files. Uh I see a message again with uh for example twelve um files uh are duplicates and can be hidden or can be uh discarded. Um but when I click this button, um uh because I went back and forth already, so I discarded them first time. uh re restore them from uh from the hidden files and then the second time I do it it only does some of them. Uh it's unclear which one are affected or if even maybe some not um copied one uh ones are affected. I don't know. Um or not dub duplicated ones I do amine. Um please investigate why this happens and please make it more uh robust. Keep it simple but uh make it more foolproof I guess. Uh or at least make sure this bug disappears.

Iterated per feedback. Two changes aimed at making the bulk discard foolproof:

1. Defensive double-key in discardItems — every target with both a sha1 and a filekey is now hidden by both, not just sha1. Belt-and-braces against any future code path that consults only one set.
2. Post-action receipt banner — after every bulk discard, a transient banner above the stash table lists the count + first three filenames it just hid (rest in the title attribute), with an Undo button that reverses exactly those rows. Auto-clears after 10s. Removes the prior uncertainty about which rows the action affected — you can read the names + click Undo before they age out. Logged to the console as [discard] for diagnostics.

Also re-snapshot duplicates inside onBulkDiscardDuplicates at click time, so any duplicate that arrived (or had its sha1 backfilled) milliseconds before the click is still hidden.

I couldn't reproduce the "only some hidden" symptom from a code read alone — discardItems collects all sha1s up-front, dedupes via hideSha1s, and triggers a single React state update — so I went for foolproof + observable rather than chasing one specific cause. If it recurs, the new console log will show exactly which sha1s/filekeys/names went into the hide.

Preview updated: https://upload-workbench.toolforge.org/mr-29/

Um there is a dynamic where when you unhide Like click on the five hidden files or the five hidden button. Uh it shows me like a a list above the the the table with the hidden files, but also the hidden files appear in the table uh underneath. in the table itself. Um and that's confusing. So that should not be the case and I guess it comes from this edit. Uh but it might come from somewhere else. But in the current version if I open up the list of hidden files, they both appear in the list of hidden files and as rows in the table. Uh the latter one is not supposed to happen So there should not be the hidden files should never be in the table rows

Iterated per feedback: hidden stash rows no longer appear in the table when the "X hidden" disclosure is open — they used to render in both surfaces simultaneously, which made bulk discard look as if rows were silently coming back. stashItems now strictly excludes hidden regardless of the disclosure toggle (no other consumer relied on the old behaviour). This is also the most plausible cause of the previous "only some hidden" symptom: the user was reading the disclosure-injected rows in the table as evidence the discard had partially failed, when only the visualisation was wrong. Defensive double-key + post-action receipt from the previous round are kept. Preview updated: https://upload-workbench.toolforge.org/mr-29/