Repository navigation
Recover catalogue CI from Trivy database download rate limits #660
Description
🤖 Generated by the Agentic Engineer
Description
Required catalogue CI on current main is red because two Go validation fixtures could not download Trivy’s vulnerability database. Dependable validation requires successful scanner setup as well as actual analysis.
Steps to Reproduce
Read CI run 39313995857, attempt 1 at 8d53a70ec7320eee70f92b5c9035a6c03797dedc. The Default-Branch Maintenance Opted Out fixture and Signed Fixes Suppressed fixture each exhaust five database-download attempts reporting TOOMANYREQUESTS. Their fallback then refuses to skip the update because no database exists on the first run.
Expected Behavior
Both fixtures obtain a valid vulnerability database and execute their full scanner set; the required aggregate passes only after successful validation. Missing scanner inputs continue to fail closed.
Actual Behavior
Both MegaLinter jobs fail during Trivy setup, and CI - Required Checks correctly fails. This is an operational database-download failure, not a clean scan or demonstrated product vulnerability. All 245 native jobs were collected with unique IDs. The Native Go Cache Policy observer itself succeeded, so this is distinct from #655’s rejected-evidence investigation and #596’s GitHub primary API quota incident.
Environment
Hosted catalogue CI, Trivy 0.74.0 through MegaLinter 10.1.0. The underlying registry-side cause and persistence remain unproven. Detailed diagnostics are retained privately.
Acceptance Criteria
- Verify complete current-main CI recovery with both affected fixtures and the required aggregate executed.
- Attribute the observed database rate limit before making any source or cache-policy change; add a focused regression if a repository defect is confirmed.
- Preserve every scanner, refusal control, database integrity requirement, credential boundary and bounded retry-exhaustion result.
- If failures persist, ship a bounded repair with real hosted proof; never convert an unavailable database into success.
Priority and Effort
High: confirmed default-branch breakage blocks reliable shared-workflow delivery. Small-to-medium diagnostic scope; this is not a measured estimate. One complete recovery attempt may test whether the transient download failure clears; queued work remains pending until collected. Part of #287.
Activity
chore: agent-claim #660 nonce=b010241807b52c6d4835a1e4db5995da
chore: agent-claim #660 nonce=7654d9c4bc61725a1eff0df24329f84c
devantler commentedon Oct 19, 2026
An existing full rerun of 39313995857, attempt 2, is already in progress at the same current-main revision
8d53a70ec7320eee70f92b5c9035a6c03797dedc. It was started by another actor before this run’s recovery write, so no duplicate rerun was dispatched.The next invocation should collect that complete attempt once and verify the two affected Trivy fixtures plus CI - Required Checks. Scanner setup, scan findings and the earlier cache-observer investigation remain separate outcomes. The failure’s underlying registry cause is still unproven; no source, credential, scanner, retry default or cache policy was changed. Recovery is pending, and this issue stays open.
chore: agent-claim #660 nonce=e1ec63ebd37e2352b69232d1a06698f4
devantler commentedon Oct 19, 2026
Verified recovery at the failed revision: run 39313995857, attempt 2 completed successfully at
8d53a70ec7320eee70f92b5c9035a6c03797dedc. All 245 native jobs were collected with unique IDs and matching revision; every job finished with a success or skipped conclusion.Both affected MegaLinter jobs executed successfully: Signed Fixes Suppressed and Default-Branch Maintenance Opted Out. Their actual logs show Trivy 0.74.0 vulnerability/misconfiguration scanning and SBOM generation completed with zero reported errors. CI - Required Checks and the separate native cache-policy observer also passed. No source, scanner, credential, retry or cache policy was changed for this observation.
This establishes recovery from the observed database-download rate limit on that immutable revision; it does not establish a permanent registry fix. Current main has since advanced to
68927b3801d388baf8243583def438d87d5cbece; its existing CI run 39315898892 was queued at collection. Keep this issue open until that current-main acceptance is collected, then close the incident only if the affected fixtures and required aggregate actually execute successfully. No additional rerun was dispatched.chore: agent-claim #660 nonce=6cef04496e67ddff79188dd85ce17eb0
devantler commentedon Oct 19, 2026
Current-main acceptance passed: catalogue CI, attempt 2 completed successfully at the independently read current default revision. All 247 native jobs were collected with unique IDs and matching revision; no failed or unfinished jobs remain.
Both affected Go validation fixtures executed successfully. Their logs confirm Trivy vulnerability/misconfiguration analysis and SBOM generation actually ran, with zero reported errors. The required aggregate also passed. This completes the recovery condition recorded above.
The observed incident was database-download rate limiting, followed by recovery without a source, scanner, credential, retry or cache-policy change. A permanent registry-side fix is not established. No additional rerun was dispatched. Closing this recovered incident; any recurrence should retain these diagnostics and be investigated without weakening scanner setup or refusal controls.
chore: agent-claim #660 nonce=3934b32ff506fb6859337a4f8ff0ab9c
chore: agent-claim #660 nonce=0e4dd3c9b7ad52c2fcbd20364007a07f