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:
parent
9b1445b3b5
commit
2fdfc702db
1 changed files with 13 additions and 0 deletions
|
|
@ -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)}"
|
||||
|
|
|
|||
Loading…
Reference in a new issue