agent packages.yml fix pinned a yanked dbt-utils version

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 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.

Not specified by the original author.

TL;DR

Editing packages.yml changes intent, not the installed code: dbt runs whatever is in dbtpackages until dbt deps runs. Run dbt deps after any packages.yml edit, confirm the installed package version in dbtpackages, and recompile. In automation, chain deps before parse or run whenever packages.yml changed (or always, it is idempotent).

agent skipped dbt deps after editing packages.yml: stale dbt_utils

Use this when

• packages.yml shows a new dbt_utils (or other package) version but behavior matches the old one
• an agent edited packages.yml and went straight to dbt run or dbt compile
• dbt_packages folder timestamps predate the packages.yml edit

Not for this skill when

• dbt deps was run and fails with a version conflict, resolve the constraints instead
• the package is installed from a local path, edits there apply without deps; check the package source type
• behavior difference comes from your override macro, not the package version

Steps

1. Compare intent versus installed: read the version in packages.yml for the package, then check the installed copy (its dbtproject.yml or version file inside dbtpackages for that package, or the lock file package-lock.yml if present). Verify: intended and installed versions are both known and their mismatch is confirmed.

2. Run dbt deps and watch its output list the package at the intended version. If a package-lock file is in use, confirm it updates consistently. Verify: deps completes and the lock or installed version matches packages.yml.

3. Run dbt parse, then compile a model that uses a macro whose behavior changed between the versions, and diff the compiled SQL against expectations. Verify: compiled SQL reflects the new package behavior.

4. Fix the agent procedure: any change to packages.yml must be followed by dbt deps in the same task, and CI should run deps before build steps unconditionally. Verify: the workflow runs deps automatically and the stale state cannot recur silently.

Variant phrasings

deps succeeds but old code persists in Cloud

dbt Cloud caches dependencies per environment in some setups; trigger a fresh job or clear the environment state if the version still lags.

git package pinned by revision

For git packages, deps resolves the revision in packages.yml or the lock; bumping a branch name without deps keeps the old checkout. Deps is still the step that moves it.

Compatibility: dbt deps and packages.yml (hub and git packages), package-lock.yml on dbt-core 1.7 and later workflows. Installed code lives in dbt_packages by default (configurable via packages-install-path).

Why it happens

dbt separates declaring dependencies from installing them, exactly like a package manager lock workflow. The runner never re-resolves packages.yml on its own, so an edited declaration with no install step is a no-op that looks like a completed upgrade. Agents that treat file edits as state changes fall for this because the file really did change; the system state did not.

Edge cases / pitfalls

• A stale dbt_packages can also mask the reverse bug: code written against new macros fails mysteriously on the old installed package.
• Commit package-lock.yml where your team uses it, so deps results are reproducible across agents and CI.
• Vendored or local packages bypass deps semantics; mixing them with hub packages in one project needs a written convention.

Provenance

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

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

Thread query: agent skipped dbt deps after editing packages.yml: stale dbt_utils

TL;DR: Editing packages.yml changes intent, not the installed code: dbt runs whatever is in dbtpackages until dbt deps runs. Run dbt deps after any packages.yml edit, confirm the installed package version in dbtpackages, and recompile. In automation, chain deps before parse or run whenever packages.yml changed (or always, it is idempotent).