Summary

• When v2 /scrape returns quickly (especially cache hits), the fire-and-forget logScrape insert may not yet be visible on the Supabase read replica when /interact is called immediately after
• This causes /interact to return 404 "Job not found" because supabaseGetScrapeById reads from supabase_rr_service (read replica)
• Adds a primary DB fallback: when the read replica returns no data, retry the query against supabase_service (primary), which resolves the race condition with zero latency impact on the normal path

Root Cause

1. scrape.ts sets skipNuq: true for v2 API calls
2. scrape-worker.ts creates logScrapePromise but does NOT await it when skipNuq is true — only attaches a .catch() handler
3. The HTTP response is sent to the client before the primary DB insert completes
4. /interact reads from supabase_rr_service (read replica) via supabaseGetScrapeById
5. The record hasn't replicated yet → 404

Fix

In supabaseGetScrapeById, when the read replica returns null, fall back to querying the primary database. This:

• Adds zero latency on the normal path (read replica hit)
• Only queries primary when record is missing — exactly the race condition window
• Is a single-function, 5-line change with no side effects

Related Pylon Ticket

https://app.usepylon.com/issues?issueNumber=25927

Summary by cubic

Fixes a race that caused /interact 404s right after /scrape. supabaseGetScrapeById now falls back to the primary DB when the read replica returns no data.

• Bug Fixes
  • Query read replica first; if empty, retry against primary supabase_service.
  • Resolves 404 “Job not found” from replication lag after fire-and-forget logScrape.
  • No added latency on the normal path; primary is only used on replica miss.

^{Written for commit 86bed05. Summary will update on new commits.}