dbt found two macros with the same name

Not specified by the original author.

TL;DR

dbt found two macros named centstodollars, usually your local copy plus one from a package such as dbt_utils, or the same file in two macro paths. Keep one: delete or rename the local copy, or namespace the call. Calls without a package prefix resolve ambiguously, so removing the duplicate restores parsing.

dbt found two macros with the same name 'cents_to_dollars'

Use this when

• dbt parse or run fails saying dbt found two macros with the same name centstodollars
• you recently added a local centstodollars macro or installed a package that provides one
• the macro exists both under macros/ and inside dbt_packages/

Not for this skill when

• you intentionally override a package macro, use the documented dispatch or rename pattern instead of a bare duplicate
• the duplicate name is a model or test, not a macro
• only one definition exists and the error names a different macro

Steps

1. Search the project and installed packages for the definition: grep for macro centstodollars across macros/ and dbt_packages/. List every file that defines it. Verify: you have the full list of defining files, usually two.

2. Decide which implementation callers should use by reading both bodies; they often differ in rounding or null handling. Check call sites by grepping for centstodollars( across models/. Verify: you know which version the models were written against.

3. Remove the duplicate: delete the local file if the package version is correct, or rename the local macro to a project-specific name such as centstodollars_local and update its call sites. Run dbt deps again if you changed packages.yml. Verify: only one definition of the name remains.

4. Run dbt parse, then dbt compile on two models that call the macro and diff the compiled SQL against expectations for rounding and nulls. Verify: parse succeeds and compiled SQL matches the chosen implementation.

Variant phrasings

duplicate appears after dbt deps

A new package version added the same macro. Pin the package version in packages.yml or drop your local copy in the same change.

duplicate within your own macros folder

A copied file left in a backup subfolder still counts if the folder is under macro-paths. Move backups outside the project paths.

Compatibility: dbt-core 1.x macro resolution across project macro-paths and dbt_packages. Package macros can be called with a package prefix to disambiguate.

Why it happens

Macro names live in a flat namespace per project unless called with a package prefix. When two definitions share a name, dbt cannot know which one a bare call means, so it errors at parse time rather than silently picking one. Local copies of utility macros are the usual second definition.

Edge cases / pitfalls

• Deleting the file is not enough if a stale copy remains in target/ or a copied project folder; search the whole repo.
• Renaming the macro without updating callers converts this error into a macro not found error.
• Behavior differences between the two bodies can change money columns; verify rounding on a known value after deduping.

Provenance

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

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

Thread query: dbt found two macros with the same name 'centstodollars'

TL;DR: dbt found two macros named centstodollars, usually your local copy plus one from a package such as dbt_utils, or the same file in two macro paths. Keep one: delete or rename the local copy, or namespace the call. Calls without a package prefix resolve ambiguously, so removing the duplicate restores parsing.

Not specified by the original author.

TL;DR

dbt cannot find the macro because the package is not installed, the dispatch config points at the wrong namespace, or you called it without the package prefix it needs. Run dbt deps and confirm the package landed in dbt_packages, then check how the macro is meant to be called. Most of these are a missing dbt deps after adding the package to packages.yml.

dbt macro not found in package, compilation failed

Use this when

• Compilation fails naming a macro from a package.
• It works on one machine but not another.
• A package was just added or upgraded.

Not for this skill when

• The macro runs but produces wrong SQL. That is a macro bug.
• Your own project's macro is missing. Check the macros directory.

Steps

1. Run dbt deps and verify the package appears in dbt_packages with the expected version. Note the package is actually installed. Verify: installation is confirmed
2. Check how the macro is namespaced: package macros need the package prefix unless dispatched. Note the correct call form. Verify: the call form is known
3. Review dispatch config if your project overrides the macro: a bad dispatch entry hides the package macro. Note dispatch resolves correctly. Verify: dispatch is ruled out
4. Fix the call or the install, then re-run dbt compile. Note compilation succeeds. Verify: the macro resolves
5. Pin the package version in packages.yml so upgrades do not move the macro. Note the version is locked. Verify: the setup is stable

Variant phrasings

dbt macro not found

The shortened search.

dbt dispatch macro package

The dispatch-shaped phrasing.

Compatibility: dbt Core 1.x. Package layout and dispatch behavior are stable; dbt_packages location is configurable.

Why it happens

dbt resolves macros across your project and all installed packages by namespace, and dispatch lets projects override package macros. That flexibility creates three ways to miss: the package was never installed where this run executes, the call uses a namespace the macro does not live under, or a dispatch entry shadows the macro you wanted. CI runners that skip dbt deps are the classic case: everything resolves locally, nothing resolves in CI.

Edge cases / pitfalls

• Private package repos need git credentials at dbt deps time. A 404 from the repo looks like a missing macro downstream.
• Two packages defining the same macro name resolve by search order. Explicit namespaces beat implicit order.
• Upgrading a package can rename or move macros. Read the changelog before bumping versions.
• dbt clean wipes dbt_packages. A clean without a following dbt deps produces exactly this error.

Provenance

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

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

Thread query: dbt macro not found in package, compilation failed

TL;DR: dbt cannot find the macro because the package is not installed, the dispatch config points at the wrong namespace, or you called it without the package prefix it needs. Run dbt deps and confirm the package landed in dbt_packages, then check how the macro is meant to be called. Most of these are a missing dbt deps after adding the package to packages.yml.

Not specified by the original author.

TL;DR

For "Compilation Error: dbt found two models with the name": upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade.

Compilation Error: dbt found two models with the name

Steps

1. Running dbt run --models +MY_MODEL+ with dbt-trino failed with a Compilation Error saying dbt found two models with the same name, even though only one model existed. This was a dbt-core bug in how the selection set was resolved, fixed upstream in dbt-core v1.5.2. Upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. The maintainer pointed at v1.5.2 as the fix and the reporter confirmed the error went away.
2. Every dbt run --models +MY_MODEL+ died with Compilation Error: dbt found two models with the name on dbt-core 1.5.0. It is not a dbt-trino problem: the fix is pip install dbt-core==1.5.2, which is the release the dbt-trino maintainer pointed to on the thread. The reporter confirmed the upgrade resolved it. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade. Source: https://github.com/starburstdata/dbt-trino/issues/311

When to use

Use this skill when you run into "Fix dbt-trino 'found two models with the name' compilation error".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: dbt-core v1.5.2, dbt-core 1.5.2, dbt-core 1.5.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/starburstdata/dbt-trino/issues/311

Question asked in the thread: Running dbt run --models +MY_MODEL+ with dbt-trino failed with a Compilation Error saying dbt found two models with the same name, even though only one model existed. This was a dbt-core bug in how the selection set was resolved, fixed upstream in dbt-core v1.5.2. Upgrade: pip install 'dbt-core==1.5.2' (and matching dbt-trino), then rerun dbt. The maintainer pointed at v1.5.2 as the fix and the reporter confirmed the error went away.

Verified answer: Every dbt run --models +MY_MODEL+ died with Compilation Error: dbt found two models with the name on dbt-core 1.5.0. It is not a dbt-trino problem: the fix is pip install dbt-core==1.5.2, which is the release the dbt-trino maintainer pointed to on the thread. The reporter confirmed the upgrade resolved it. Keep dbt-core and dbt-trino version-compatible when you bump, and rerun your model selection after the upgrade. Source: https://github.com/starburstdata/dbt-trino/issues/311

Thread: https://vectle.com/threads/thr_KFsdNfhM6YD99kT1COzCzA