Modelling correctness · rule duplicate-source
dbt sources declared twice for one table
A Metacenta review checks this under the rule Each warehouse relation is declared as a source once. Everything below applies whether or not you ever commission one.
What this rule checks
This rule flags any warehouse relation declared as a dbt source more than once. We compare the resolved database, schema and identifier, ignoring case. The source names in YAML play no part, since two names for one table is the mistake itself.
Why it matters
Lineage splits across the duplicates, so any graph of what reads the table is wrong. A freshness check or schema change applied to one declaration leaves the others stale.
How to fix it
Declare each warehouse relation as a source once. Keep one source definition for the relation, and repoint every source() call at it.
Before:
sources:
- name: shop
schema: raw
tables:
- name: orders
- name: shop_legacy
schema: raw
tables:
- name: orders
After:
sources:
- name: shop
schema: raw
tables:
- name: orders
When it is fine to leave
Rarely, and only for a short time. During a migration from one source name to another, both may exist until the last source() call moves over. Remove the old one as soon as nothing reads it.
What we need to check it
manifest.json alone. A source with no resolved database, schema or identifier is left out, because two half-known relations cannot be told apart. If no source is fully resolved, the rule says it could not assess.
Published rules it corresponds to
dbt_project_evaluator, rule fct_duplicate_sources. Ours checks the same condition and threshold.
This means our check corresponds to their rule. It does not mean the publisher reviewed or endorses it.