Skip to content

Fix parallel chunk scanning shared DB connection race (v2.6.38)#47

Merged
ttlequals0 merged 1 commit intomainfrom
fix/parallel-chunk-shared-checker
Apr 6, 2026
Merged

Fix parallel chunk scanning shared DB connection race (v2.6.38)#47
ttlequals0 merged 1 commit intomainfrom
fix/parallel-chunk-shared-checker

Conversation

@ttlequals0
Copy link
Copy Markdown
Owner

Summary

  • Parallel chunk workers shared a single PixelProbe StaticPool DB connection, causing silent write loss in _save_to_cache() -- files marked completed without scan_date or scan_tool being set
  • Each chunk worker thread now gets its own PixelProbe instance via threading.local() with engine disposal after scanning
  • Regression introduced in v2.6.32 (parallel chunk refactor), masked by v2.6.36 raw SQL UPDATE fix

Test plan

  • 313 tests passed, 0 failures
  • Deploy and trigger manual scan with new files on disk
  • Verify all scanned files have scan_date and scan_tool set (not NULL)
  • Check Grafana: "Successfully saved" count matches total files scanned

…ds (v2.6.38)

Parallel chunk workers (v2.6.32+) shared the parent PixelProbe instance
which uses StaticPool with a single DB connection. Concurrent _save_to_cache()
calls from 3+ threads caused silent write loss -- files ended up with
scan_status='completed' but scan_date=NULL. The v2.6.36 raw SQL UPDATE
masked this by marking unscanned files as done.

Fix: each chunk worker thread gets its own PixelProbe instance via
threading.local(), with tracked engine disposal after scanning completes.
@ttlequals0 ttlequals0 merged commit ccd8788 into main Apr 6, 2026
6 checks passed
@ttlequals0 ttlequals0 deleted the fix/parallel-chunk-shared-checker branch April 6, 2026 23:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant