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

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