{{ message }}
fix(api): set finite backlog timeout for crawl jobs#3412
Open
firecrawl-spring[bot] wants to merge 1 commit intomainfrom
Open
fix(api): set finite backlog timeout for crawl jobs#3412firecrawl-spring[bot] wants to merge 1 commit intomainfrom
firecrawl-spring[bot] wants to merge 1 commit intomainfrom
Conversation
Crawl/batch-scrape jobs enqueued into the NuQ concurrency backlog were stored with times_out_at=NULL, which nuq_queue_scrape_backlog_reaper does not clean (its filter is times_out_at < now()). If the concurrency-queue reconciler never promotes a row (crawl abandoned, worker restart, etc.), the orphaned backlog row persists forever — and nuq_group_crawl_finished blocks on its NOT EXISTS check against the backlog, leaving the group stuck in 'active' indefinitely. Give crawl-linked backlog rows a 24h fallback timeout (matches crawl Redis state TTL and default group_crawl.ttl). If a crawl is still actively producing work past 24h, promoteJobFromBacklogOrAdd already falls back to addJobIfNotExists when the backlog row is missing, so re-enqueue is handled. Co-Authored-By: micahstairs <micah@sideguide.dev>
3 tasks
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
tomsideguide
approved these changes
Apr 21, 2026
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
times_out_at = NULL. Thenuq_queue_scrape_backlog_reapercron only deletes rows wheretimes_out_at < now(), so NULL rows live forever.nuq_group_crawl_finishedhas aNOT EXISTScheck againstqueue_scrape_backlog, so any stale NULL row on a group permanently blocks the crawl from flipping tocompleted→ crawl appears stuck indefinitely in the UI.019dae72-0d94-7723-ab1e-2c078084583b: 0 active/queued scrape rows, 4 backlog rows withtimes_out_at IS NULL.Fix
Give crawl-linked backlog rows a finite 24h fallback timeout (matches crawl Redis state TTL and default
group_crawl.ttl). Standalone-scrape behavior is unchanged (still uses the per-scrape timeout).If a crawl is genuinely still producing work after 24h,
promoteJobFromBacklogOrAddalready falls back toaddJobIfNotExistswhen the backlog row has been reaped (nuq.ts:1069-1073), so we'll re-enqueue fresh rows in that edge case.Paired with
#3413 — defensive fallback in
nuq_queue_scrape_backlog_reaperto sweep NULL/stale rows that predate this fix.Test plan
nuq.queue_scrape_backlogrows for that group →times_out_atis non-NULLscrapeOptions.timeout