[thedancingdeveloper]

WI-1721: toasts with undo for destructive actions (including a backend soft-delete). Written by a DeepSeek worker.

🤖 Generated with Claude Code

[thedancingdeveloper]

Review of 968a58c: no blockers (CI pending), with 4 should-fix data-safety items. GitHub rust and e2e were still pending; frontend passes.

Checks run locally:

• cargo test -p nzb-core --lib passes 207/207, every nzb-web suite passes (lib 269/269), and --test history_bulk_api passes 8/8.
• cargo clippy --workspace --all-targets -D warnings and fmt --check are clean.
• ng test passes 285/285 and lint is clean.
• No Cargo.lock changes.

Data safety: what's right

• API compatibility. DELETE /api/history/{id} without ?trash=true is still the old hard delete returning {status: true}. SABnzbd and *arr clients and "clear all" are unchanged. POST /api/history/bulk only gains an optional trashed field (skip_serializing_if), and /api/history/restore is additive.
• Soft delete is invisible everywhere. Migration v20 adds trash and trash_deadline, and mirrors trash into history_list_meta, so list queries don't walk the blob overflow chain. Every read filters trashed rows: list, count, categories, summaries (and so the SABnzbd compat API), history_get (and so retry and detail), history_get_listed, and the duplicate check.
• Retention skips trashed rows, so it can't consume an open undo window.
• The undo is lossless. The row keeps its NZB and retry blobs. While it's trashed, its work directories count as referenced, so the orphan sweep can't take them.
• Restore is per-id, honours trash_deadline >= now, and reports late or unknown ids as failures. The UI turns those into "N could no longer be undone".
• Eventual hard delete. history_purge_expired runs from the periodic loop every 30 ticks. It deletes expired rows, then drops orphan ledger rows, and it's deadline-based, so it also catches up after a restart. The RFC 3339 string comparison is safe here: everything is +00:00, and + sorts before . and the digits.
• The toast is clamped to the server's purge_after. Clock skew can only shorten it (1 s floor), never stretch it past the window.

Should fix

1. A large clear can hand out an undo that's already expired. In h_history_bulk, deadline = now + 10s is computed before the per-id loop. Each id is a history_get, which loads its blobs, plus its own history_trash transaction, so clearing a few thousand failed entries can take longer than 10 s. The response then offers an Undo whose window has already closed, and the concurrent 30 s purge can hard-delete the earliest rows mid-request. The user did confirm a clear-by-status, so no data is lost beyond intent, but the undo promise is broken. Either trash the whole status set in one UPDATE … WHERE with the deadline taken after the commit, or compute the deadline after the loop and re-stamp the trashed rows with it.
2. Any later toast silently cancels the Undo. MatSnackBar shows one snackbar at a time, so a second delete, a poll error or any other toast inside the 10 s closes the first Undo for good. Bulk delete also no longer asks for confirmation ("Undo is the confirmation"), so two quick deletions leave the first one unrecoverable from the UI. Merge pending undos into one toast ("Deleted 5 entries · Undo"), or keep the confirmation dialog for bulk delete.
3. Purging a trashed Failed entry doesn't reclaim its retry-checkpoint directory. QueueManager::history_purge_expired calls history_work_dirs(&db, id, status) after db.history_purge_expired has deleted the rows. For a Failed entry that function reads db.history_get_retry_data(id), which now returns nothing, so only incomplete/<id> is reclaimed and the checkpoint directory is left for the orphan sweep (if it scans that location). history_remove gets the order right. Collect the directories inside the DB call before the DELETE, and add a test with a failed entry that has a retry checkpoint.
4. The v20 trigger broadens v19's scoping. v18/v19 deliberately defined history_list_meta_update as AFTER UPDATE OF <list columns>, so blob writes (nzb_data, retry_data, job_logs) don't rewrite the meta row. v20 recreates it as a bare AFTER UPDATE ON history, which is correct but fires on every history update. Use AFTER UPDATE OF id, download_time_secs, server_stats, failure_code, post_processing, delete_archives, par2_volumes_fetched, par2_volumes_available, trash.

Nits

• This conflicts with feat(ui): keyboard shortcuts; fix e2e locator collisions (WI-1721) #246. e2e/tests/queue.spec.ts (4.7) and downloads-mock.spec.ts carry the same locator fix as feat(ui): keyboard shortcuts; fix e2e locator collisions (WI-1721) #246, with different text on the same lines. Whichever lands second needs a rebase; keep one version.
• A 10 s Undo is short for keyboard and screen-reader users. The snackbar action doesn't take focus. The polite "Undo available" announcement helps, but WCAG 2.2.1 suggests a longer window or a way to reach it, for example a 20 s server window, or keeping the most recent trash restorable from the History page.