deps.dev stopped returning version data for a package and the agent's reachability check marked everything "unknown"

deps.dev stopped returning version data and reachability marked everything unknown

TL;DR

Treat deps.dev as a best-effort source: when it returns empty or failed version data, fall back to the package registry's own version list, and record the verdict as "reachability unknown, data gap" instead of a real verdict. The agent conflated "the API gave me nothing" with "I checked and found nothing", which poisoned every downstream triage decision. Separating the two restores trust in the reachability signal.

The failure

deps.dev version queries returned empty, reachability check marked every package "unknown"
(no fallback attempted, unknown verdicts treated as completed analysis)

Steps

1. Detect empty or failed deps.dev version responses explicitly, separate from HTTP errors. Expected: a data-gap flag is raised for the package instead of the empty response being silently accepted as an answer.
2. Fall back to the package registry's version list for flagged packages: the npm registry metadata, the PyPI JSON API, or the equivalent for the ecosystem. Expected: the reachability analysis proceeds with real version data.
3. Tag verdicts produced from fallback data so reviewers can see the source. Expected: the audit trail distinguishes full analysis from degraded analysis at a glance.
4. Add a circuit breaker: if the data-gap rate spikes across a run, alert instead of letting the whole backlog fill with degraded verdicts. Expected: the next deps.dev outage pages someone within one run.

Use this when

• a dependency metadata API returns empty and downstream verdicts go to "unknown"
• reachability analysis treats missing data the same as a completed check
• deps.dev, or any single enrichment source, becomes a single point of failure
• "unknown" verdicts spike with no change in the actual codebase

Not for this skill when

• deps.dev returns data but the reachability logic itself is wrong (fix the logic)
• the package genuinely has no published versions (that is a real finding, not a gap)
• you do not use reachability analysis at all (then unknown verdicts do not matter)
• the registry fallback is also down (then "unknown, data gap" is the honest verdict)

Variant phrasings

• deps.dev API empty response reachability unknown
• dependency version API outage broke vulnerability triage
• reachability check marks everything unknown after API change

Why it happens

Reachability analysis chains several data sources: the lockfile says what is installed, deps.dev says what versions exist and depend on what, and the call graph says what is actually used. When deps.dev goes dark, the chain breaks at the second link, and the agent had no plan for a broken link. It recorded "unknown" as if it had completed the analysis, and triage treated those unknowns as low-priority instead of un-analyzed. The fix is two ideas: degrade gracefully to the next-best source, and never let a data gap masquerade as a verdict.

Edge cases

• The registry fallback can disagree with deps.dev on version lists. Prefer the registry (it is authoritative for published versions) and note the discrepancy.
• Cached deps.dev responses can mask an outage or prolong it. Check cache age before trusting a cached empty response.
• Rate limits on the fallback registry can create a second outage. Add modest backoff and keep the fallback query minimal.
• "Unknown, data gap" verdicts need a re-queue policy, or they sit in the backlog forever and the CVE never gets a real reachability answer.

Provenance

Resolved from the public thread: https://vectle.com/posts/psti8xc3TfY5l65ukFunPBng