agent couldn't reach the internal Artifactory — the VPN dropped mid-run and it pinned everything to public versions

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.

Not specified by the original author.

TL;DR

The repo host allowlists IPs and the agent's egress IP is not on it. Add the runner's egress IPs to the allowlist, or run the agent on a self-hosted runner with a stable IP.

Error

agent failed to access the repo host: ip allowlist blocked its egress error

Steps

1. Confirm the block is IP-based: the error names the IP policy, and other networks work. Expected: the cause proven.
2. Find the agent runner's egress IPs (they may be a range). Expected: the IPs known.
3. Add them to the repo host's IP allowlist. Expected: access granted.
4. If egress IPs are dynamic, move the agent to a self-hosted runner with a static IP. Expected: stable access.
5. Re-run the agent's access. Expected: success.

When to use

• IP allowlist blocks on agent egress.
• Setting up agents against locked-down hosts.

When not to use

• Auth failures (fix credentials).
• DNS issues (different problem).

Tool compatibility

• Repo host IP allowlists; self-hosted runners.

Variant phrasings

ip allowlist blocked agent

Allowlist the egress.

egress blocked by ip policy

Same fix.

Why it happens

Security-conscious hosts restrict by IP; cloud runners have dynamic egress that is not on the list.

Edge cases

• Egress ranges change; monitor for new blocks.
• Allowlisting wide ranges weakens the control; prefer static IPs.
• Some hosts support runners as apps instead of IP rules; prefer that.

Provenance

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

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

Thread query: agent failed to access the repo host: ip allowlist blocked its egress error

TL;DR: The repo host allowlists IPs and the agent's egress IP is not on it. Add the runner's egress IPs to the allowlist, or run the agent on a self-hosted runner with a stable IP.

Not specified by the original author.

TL;DR

The version pinned in packages.yml does not exist in the registry (or the registry moved). Check the package's real version list, pin one that exists, delete the stale entry from package-lock.yml if present, and re-run dbt deps.

Error

dbt deps: package version not found

Steps

1. Open packages.yml and note the package name and pinned version or range. Expected: You have the exact requirement, e.g. version: 1.2.3 or a range.

2. Check the package hub (hub.getdbt.com) listing for the package and its published versions. Expected: You see whether 1.2.3 was ever published, yanked, or never existed.

3. Pin a version that exists, preferably the latest compatible with your dbt-core. If a package-lock.yml exists, delete it so the new pin resolves fresh. Expected: packages.yml references a real version.

4. Run dbt deps and then dbt compile to confirm the package loads. Expected: Packages install, compile succeeds.

When to use

• dbt deps fails saying a package version was not found
• a version range that used to resolve now fails (old versions yanked)
• after copying packages.yml from another project with different dbt-core

When not to use

• git authentication errors on git-based packages (that is credentials, not the registry)
• network timeouts reaching the hub (that is connectivity)
• the package installs but a macro inside it fails (that is macro code, different fix)

Tool compatibility

• dbt deps resolves from hub.getdbt.com for registry packages
• package-lock.yml pins exact resolved versions; delete to re-resolve
• dbt-core version compatibility is listed per package release

Variant phrasings

package version not found after dbt upgrade

The pinned version may cap dbt-core below your new version. Bump the package pin to a release supporting your dbt-core.

version not found for a git package

Git packages use revision, not version. Check the tag or commit exists in the repo; a deleted branch breaks the pin.

Why it happens

The registry only serves versions the maintainer published. Pins copied between projects, ranges that exclude everything compatible, and yanked releases all produce this. dbt will not guess a nearby version; it fails loudly.

Edge cases

• A too-tight range like 1.0.x-only fails if every 1.0.x release was yanked; widen the range or pin an exact version that exists.
• Private registries need the registry URL configured; otherwise dbt looks on the public hub and will not find your package.

Provenance

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

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

Thread query: dbt deps: package version not found

TL;DR: The version pinned in packages.yml does not exist in the registry (or the registry moved). Check the package's real version list, pin one that exists, delete the stale entry from package-lock.yml if present, and re-run dbt deps.