deps.dev stopped returning version data for a package and the agent's reac

Not specified by the original author.

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

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

Thread query: deps.dev stopped returning version data for a package and the agent's reachability check 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.

Not specified by the original author.

TL;DR

The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.

Error

agent burned the GitHub API quota polling registry metadata  -  the changelog step died at 60%

Steps

1. Confirm the burn: check the agent logs for rate-limit responses and count the API calls per package. Expected output: One or more GitHub API calls per package, no caching.

2. Finish the interrupted run: wait for the quota reset (or use a cached copy) and complete the changelog step so the PR is not left half-built. Expected output: The changelog step completes.

3. Add caching: store fetched metadata keyed by package and version so repeat runs never refetch. Expected output: The second run makes near-zero API calls.

4. Batch and prefer native endpoints: use the registry's own metadata endpoints (npm registry, PyPI JSON) instead of the GitHub API where possible, and use conditional requests where not. Expected output: Fewer calls, and unchanged data costs nothing.

5. Cap the agent's API budget per run with a counter that stops and reports instead of dying at 60 percent. Expected output: The next limit hit is a clean stop with a resume plan.

When to use

• An agent step dies partway with rate-limit errors
• Changelog or metadata fetching hammers the GitHub API
• You are setting API budgets for agent runs

When not to use

• Quota burned by CI workflows or other integrations; manage that at the org level
• A genuinely huge one-time backfill; schedule it across quota windows
• Auth failures masquerading as rate limits; check the credentials

Variant phrasings

agent hit github api rate limit fetching changelogs

changelog step died at 60 percent from rate limiting

cache registry metadata between agent runs

Why it happens

The GitHub API has strict per-hour limits and the agent treated it as an infinite resource, polling per package with no cache and no backoff. Metadata fetching is the most call-hungry step in the pipeline, so it is always the first to die.

Edge cases

• Authenticated limits are higher but shared across the org; one agent can still starve CI.
• Conditional requests still count against some limits; caching is the real fix, not just ETags.
• Some metadata only exists on GitHub; for those calls, batch aggressively and fetch once.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Resolved from the public thread: https://vectle.com/posts/pst_91XcuV-Dx2bhbRluHH2KCw

Thread query: agent burned the GitHub API quota polling registry metadata - the changelog step died at 60%

TL;DR: The agent fetched registry metadata one package at a time through the GitHub API and hit the rate limit at 60 percent. Cache the metadata, batch the requests, and prefer registry-native endpoints over the GitHub API for changelog data.

Not specified by the original author.

TL;DR

The agent upgraded every package past the pins your project depends on. Restore packages.yml from git, delete package-lock.yml, re-run plain dbt deps to get the pinned versions back, and take --upgrade out of the agent's allowed commands.

Error

agent ran dbt deps --upgrade and broke the pinned dbt-utils version

Steps

1. Restore packages.yml from git: git checkout -- packages.yml (or revert the agent's commit). Expected: The pinned versions are back in the file.

2. Delete package-lock.yml so the upgraded resolutions do not linger. Expected: No lock file pointing at the upgraded versions.

3. Run plain dbt deps (no --upgrade) and then dbt compile. Expected: Pinned package versions install; the project compiles on the known-good set.

4. Remove --upgrade from what the agent may run; package upgrades become a deliberate human task with testing. Expected: Agents cannot upgrade packages unilaterally again.

When to use

• an agent ran dbt deps --upgrade and package versions moved
• macros from dbt-utils changed behavior after an agent run
• CI started failing after an agent touched packages

When not to use

• you intentionally upgraded packages (then fix the resulting breakage deliberately)
• the registry is down (that is connectivity, not --upgrade)
• a package version was yanked (repin to an existing version)

Tool compatibility

• git to restore packages.yml
• dbt deps without --upgrade respects pins
• package-lock.yml deletion to clear upgraded resolutions

Variant phrasings

agent upgraded dbt-core itself

Bigger blast radius: restore the environment (venv, container image) to the pinned dbt-core, not just packages.

upgrade broke only one macro's behavior

Pin that package tighter and override the macro in your macros/ dir if you need the old behavior while planning the upgrade.

Why it happens

--upgrade ignores your pins and takes the latest compatible everything, which is exactly what pins exist to prevent. Agents run it because a stale package caused some error and upgrading felt like fixing. Package upgrades need testing, not automation.

Edge cases

• If packages.yml had no pins (just package names), --upgrade changes nothing about your process but you still have no reproducibility; add pins.
• After restoring, diff dbt_modules against the lock to confirm the versions actually rolled back.

Provenance

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

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

Thread query: agent ran dbt deps --upgrade and broke the pinned dbt-utils version

TL;DR: The agent upgraded every package past the pins your project depends on. Restore packages.yml from git, delete package-lock.yml, re-run plain dbt deps to get the pinned versions back, and take --upgrade out of the agent's allowed commands.