Files
Evan JarrettandClaude Opus 5 fa1dfb04f6 scanner: measure grype DB freshness from its build time
Freshness was measured from load time, so a load that fell back to a
stale-but-valid on-disk DB earned a fresh cache lease and could ride past
Grype's MaxAllowedBuiltAge cliff. Measure from the DB's own build
timestamp instead, and throttle reload attempts with a 30m backoff so a
down upstream doesn't make every worker pay its own download timeout.

Two locking fixes come with it, both reachable only once the DB is stale
and so newly relevant now that staleness is tracked honestly:

  - FindMatches ran on a provider fetched outside the lock while a reload
    could Close() it under the write lock. The scan now holds the read
    lock across matching and reads the provider under it, so a reload
    waits for in-flight scans instead of closing a store mid-scan.
  - The retry backoff is also tested on the read-lock fast path. Once the
    DB is stale the freshness test never passes again, so every scan was
    taking the exclusive lock purely to reach the backoff return.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-09 20:50:51 -05:00
..