Downloads: race guard ignores stale duplicate calls after quarantine

When a file is quarantined (AcoustID / integrity / bit-depth), the source
is moved away and _mark_task_quarantined sets _quarantine_entry_id on the
context.  A second post_process_matched_download call with the same
file_path (caused by a monitor re-poll or concurrent dispatch before the
context is cleaned up) then hit the race guard — "source file gone, no
known destination" — and overwrote the in-flight retry with a failed status.

Fix: check _quarantine_entry_id before firing the race guard.  If it is
set, the file is legitimately in quarantine and this is a stale duplicate;
return silently so the quarantine retry already in flight can proceed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
dev 2026-06-06 00:59:38 +02:00
parent 9b1445b3b5
commit 2fdfc702db

View file

@ -207,6 +207,19 @@ def post_process_matched_download(context_key, context, file_path, runtime, meta
f"{os.path.basename(existing_final)}"
)
return
# File was intentionally moved to quarantine by a concurrent/earlier
# post-process call — this is a stale duplicate dispatch, not a race.
# _mark_task_quarantined sets _quarantine_entry_id for every quarantine
# trigger (AcoustID, integrity, bit-depth). The quarantine entry and
# its retry are already in flight; don't overwrite the task state with
# a spurious race-guard failure.
if context.get('_quarantine_entry_id'):
logger.debug(
f"[Race Guard] Source gone but already quarantined (entry %s) — stale duplicate call, ignoring: "
f"{os.path.basename(file_path)}",
context['_quarantine_entry_id'],
)
return
logger.error(
f"[Race Guard] Source file gone and no known destination — marking as failed: "
f"{os.path.basename(file_path)}"