fix(triage): cache Referrers-API support per registry to skip slow oras discover#112
Merged
Merged
Conversation
…as discover JFrog has no OCI Referrers API, so `oras discover` does not fail fast — it hangs until the timeout — making retrieve-triage pay the full ~15s probe per image, plus up to ~360s more per untriaged image via the legacy triage.toml path (which also calls oras discover despite a comment saying it should be skipped once the Referrers API has timed out). Add a process-wide RegistryCapabilityCache: the first Referrers-API timeout marks that registry host unsupported, and every later image on the same host skips both oras-discover probes and falls straight through to tag-based cosign attestation. On a 41-image JFrog list this drops oras discover calls from 41 to 1 and the run from ~14m to ~4m, with no change in which images get triage.
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.
Problem
retrieve-triage -i <images>against JFrog is slow and looks broken: every image logsoras discover ... timed out after 15s. JFrog doesn't implement the OCI Referrers API, sooras discoverhangs to the timeout instead of failing fast — and we pay that once per image. Worse, the legacytriage.tomlfallback also callsoras discover(full timeout, twice counting the--plain-httpretry) even though its own comment says it should be skipped once the Referrers API has timed out — so any image without a tag-based attestation burns up to ~360s.The triage itself was already fetched correctly via the tag-based cosign fallback (#104); this PR is purely about the wasted time and the misleading timeout spam.
Change
Add a process-wide
RegistryCapabilityCache(mirrors the existingDigestCache):_discover_referrersreturns immediately when the host is already known to lack the Referrers API, and records the host on the first timeout (both the digest-based and tag-based probes).fetch_triage_for_imageskips the legacytriage.tomlpath for such hosts (honoring the existing comment), going straight to tag-based cosign attestation.Only the negative signal (timeout) is cached, per registry host — a non-timeout failure still falls through unchanged, and Harbor (which supports Referrers) is unaffected.
Effect (measured on a 41-image JFrog list)
oras discovercalls: 41 → 1Test
python3 -m scanner_py retrieve-triage -i <41 jfrog images> -o triage -r report.md -v— confirmed 1 totaloras discovercall, 40 "Skipping Referrers API" debug hits, and every triaged image fetched.