Evaluate status feedback for long-running archive deletion

[borg-codex-bot]

Status and scope

Backlog item for later evaluation. The maintainer has not selected either implementation variant below. This issue records both alternatives; it does not authorize implementation or commit to a release date.

Follow-up to #507 (deleting an individual repository archive).

Problem

Deleting a very large archive leaves the confirmation dialog blocked for a long time. Users cannot tell whether Borg is working, waiting, or stuck, and they cannot see what happened until the request finishes.

The current implementation:

• Disables every button and input in the delete dialog, including closing it.
• Sends one synchronous DELETE request to /api/repositories/archive.
• Runs borg delete with captured output and a fixed 3600-second timeout, without forwarding intermediate progress to the UI.
• Refreshes repository information after deletion before returning the response.
• Displays a static waiting message throughout these different phases.

Relevant code: ui/js/pages/storage.js (confirmRepositoryArchiveDelete, closeRepositoryArchiveDelete) and api/repositories_api.py (delete_repository_archive). The blocked dialog does not by itself establish that the entire backend is hung.

Option A: Improve the existing blocking dialog

• Keep the current synchronous deletion workflow and blocked dialog.
• Add an activity indicator, elapsed time, and clear wording that large archives may take longer.
• Show a concise result or error when the request completes.
• Clearly distinguish a locally running timer from actual Borg progress: a spinner alone must not claim that Borg is making progress or that the server is responding.

Trade-off: smaller implementation scope, but the dialog remains blocking. The existing request alone cannot expose live Borg messages or distinguish deletion from the subsequent statistics refresh. Adding those features would require backend status support as well.

Option B: Background deletion with a reopenable status view

• Start the deletion as a tracked background operation and return an operation identifier promptly.
• Display the current phase: validate repository/archive, delete archive, refresh repository statistics, complete.
• Show elapsed time, last successful status update, and last Borg message separately.
• Allow the status window to be closed without stopping deletion. Keep a visible activity indicator on the repository and allow the status view to be reopened after navigation or a browser reload.
• Keep unrelated pages usable while preventing conflicting operations against the affected repository.
• Offer a collapsed "Borg details" section with bounded, sanitized output rather than an ever-growing live log.
• If the status connection fails, show that the status is temporarily unavailable and reconnect. Do not automatically retry the destructive operation.
• Show the final archive, repository, duration, outcome, and warnings. A failed statistics refresh must not turn a successful deletion into a deletion failure.

Trade-off: more backend and UI work, including operation lifecycle, reconnect handling, duplicate-start protection, and restart/interruption semantics. Existing maintenance and restore background-operation patterns should be evaluated for reuse without a broad refactor.

Points to evaluate before choosing a variant

• Borg --progress and --log-json can provide structured messages. Display percentages only when Borg supplies them, scoped to the actual phase rather than an invented overall percentage or ETA.
• Distinguish "server responds", "process still running", and "Borg reports progress". No new output does not by itself prove either a hang or ongoing progress.
• Review the fixed one-hour timeout for large archives and remote repositories; do not silently remove limits or add automatic destructive retries.
• Keep successful deletion distinct from physical space reclamation: Compact remains a separate, explicitly initiated maintenance action.
• Preserve authenticated-admin authorization, explicit DELETE confirmation, repository/archive identity checks, resource locking, cache invalidation, and audit records.
• Bound transient output in RAM and avoid persisting every progress update to the Unraid boot flash. Retain useful start, completion, warning, and error records.
• Provide German and English UI text and accessible status announcements without repeated notification noise.

Validation after a decision

• Slow deletion with progress, long periods without Borg output, warnings, command failure, and timeout.
• Successful deletion followed by a failed or slow repository-statistics refresh.
• Conflicting operations remain blocked and another archive cannot be deleted through duplicate submission.
• For Option B: closing/reopening, navigation, browser reload, lost connection, and plugin restart/interruption produce accurate status and never trigger an automatic repeat deletion.

Decision required

• Select Option A or Option B and agree on the exact scope before implementation.

Expected user impact when implemented: clearer feedback and outcome reporting for long-running archive deletion. User-facing release notes will be required for the eventual implementation; no code or release work is part of creating this issue.

References:

• https://borgbackup.readthedocs.io/en/stable/usage/delete.html
• https://borgbackup.readthedocs.io/en/stable/internals/frontends.html