dbt found two macros with the same name 'cents_to_dollars'

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

Two models share a name, usually after a copy-paste or a staging/prod folder split. Rename one, or disable the one you dont need with enabled: false in its config. Then dbt ls to confirm each name resolves to exactly one node.

Error

dbt AmbiguousAliasError: duplicate model name in project

Steps

1. Run dbt ls --resource-type model and grep for the duplicated name to find both files. Expected: Two file paths show up for the same model name, e.g. models/staging/stgorders.sql and models/marts/stgorders.sql.

2. Decide which one is canonical. Rename the other file and its references, or add {{ config(enabled=false) }} to the top of the one you want to keep out of the DAG. Expected: Only one enabled model carries the name.

3. Search the project for ref('old_name') calls that pointed at the renamed or disabled model and update them. Expected: No refs point at the old name; grep for it returns nothing.

4. Run dbt ls again and then dbt compile for the full project. Expected: Each model name appears once, compile succeeds with no AmbiguousAliasError.

When to use

• dbt raises AmbiguousAliasError or found two resources with the same name
• you duplicated a model file to try a variant and forgot to rename it
• a merge brought in a second model with the same name

When not to use

• duplicate column names inside a single model's select (that is a SQL error, not this)
• two models with similar but different names
• the error is about sources or seeds, which have their own dedupe rules

Tool compatibility

• dbt-core all versions; node naming rules unchanged
• dbt ls is the fastest way to list every node name
• dbt Cloud IDE shows the same error on compile

Variant phrasings

dbt found two resources with the same name

Same error, older wording. The fix is identical: one name, one enabled node.

duplicate name across packages

Your project and an installed package both define the name. Use enabled: false on the package model via your dbt_project.yml, or rename yours.

Why it happens

dbt addresses models by name in ref(), so names must be unique across the whole project including installed packages. Duplicates usually come from copying a model as a starting point, or from a folder restructure where the old file was not deleted.

Edge cases

• Disabled models still show in dbt ls unless you filter; use dbt ls --exclude to sanity check the live DAG.
• Snapshots and seeds share the namespace too, a seed and a model with the same name triggers the same error.

Provenance

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

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

Thread query: dbt AmbiguousAliasError: duplicate model name in project

TL;DR: Two models share a name, usually after a copy-paste or a staging/prod folder split. Rename one, or disable the one you dont need with enabled: false in its config. Then dbt ls to confirm each name resolves to exactly one node.