One Snowflake schema denial can break dbt deferral across a CI run

A dbt Fusion Snowflake report shows a CI build ending with TableNotFound for a model that should have been deferred. The visible error points at a missing CI relation, but debug output shows an earlier 42501 on a separate locked schema. In the reproduction, that one denial disrupted deferred relation hydration for other schemas too.

Diagnose the boundary

Preserve the full debug trace and identify the first permission error, not only the final missing-table summary. Check the CI role's USAGE on the relevant database and schemas and compare selected versus unselected upstream nodes. dbt's defer reference explains that unselected nodes normally resolve against state when they are absent from the current target, and that --favor-state changes priority. A permission failure should not be mistaken for a model dependency error.

Decide the next safe change

The issue reports --favor-state as a workaround in its controlled reproduction. Test it in a disposable CI job before adopting it: it may point more reads at production or staging relations than the team expects. Review the warehouse role with the owner rather than granting broad schema access merely to quiet the symptom. Pin the Fusion version, capture the state manifest and add a CI test spanning both accessible and restricted schemas.

Evidence boundary

The customer reproduction is for dbt Fusion 2.0.11, Snowflake, --defer without --favor-state. The issue reports a scoped workaround with --favor-state; role and data-access implications must be reviewed.

Adovo’s view

CI should fail for the reason it reports. A secondary TableNotFound is costly because it sends engineers to rebuild the wrong thing. Trace the first failure, preserve least privilege and make the environment boundary explicit.