fix: re-check FreqBlog 'queued' (202) tracks once within the same run#6
Open
gnujoow wants to merge 1 commit into
Open
fix: re-check FreqBlog 'queued' (202) tracks once within the same run#6gnujoow wants to merge 1 commit into
gnujoow wants to merge 1 commit into
Conversation
A 202 from /lookup means an on-demand analysis was just triggered and is usually ready within ~15-60s. Previously the track only got retried on the next enrich run (next day's cron in production), so a playlist enriched interactively looked 'failed' even though the data was ready seconds later. enrich_pending now collects queued tracks and, after the main pass, waits QUEUED_RECHECK_DELAY (30s) and re-looks them up once: - ok → stored immediately (no second attempt bump for the same run) - rate_limited → stop, remaining tracks stay pending for the next run - still queued / not_found → left pending; next run retries them first (attempts DESC ordering) as before Each re-check spends a request the next-run retry would have spent anyway, so monthly quota use is net neutral. The re-check is skipped when the main pass already hit the rate limit. Fixes #2 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #2.
A 202 from
/lookupmeans an on-demand analysis was just triggered and is usually ready within ~15–60s. Previously a queued track was only retried on the next enrich run (the next day's cron in production), so enriching a playlist interactively left tracks looking failed/pending even though the data was ready seconds later.Note:
bump_enrich_attempt(id, MAX_ATTEMPTS)passesMAX_ATTEMPTSas the limit (not the attempt count), so queued tracks were never immediately terminal — but the practical pain in the issue is real: without an in-run re-check, the drip design makes freshly queued tracks wait a full day per attempt.Changes
enrich_pendingnow collects queued tracks and, after the main pass, waitsQUEUED_RECHECK_DELAY(30s) and re-looks each up once:attempts DESCordering), unchangedThe re-check is skipped entirely when the main pass already hit the rate limit. Quota impact is net neutral: each re-check spends the request that the next-run retry would have spent anyway — it just lands the data today instead of tomorrow.
The ok-handling block is extracted into
_store_ok()so the main pass and the re-check share it.Tests
5 new tests (plus an autouse fixture stubbing
time.sleep): recovery within the run, single attempt bump when still queued, partial-on-recheck stays pending without an extra bump, re-check skipped after a main-pass 429, and re-check aborting on a 429 mid-pass. Existing queued/MAX_ATTEMPTS drip semantics are unchanged and still covered.150 passed(baseline 145).🤖 Generated with Claude Code