agent reordered models in the dag and broke the snapshot dependency

TL;DR

A snapshot must run after the models feeding it. If DAG edits (renamed refs, removed dependencies, or orchestrator reordering) let the snapshot run first, it snapshots yesterdays upstream state or fails on a missing relation. Restore the dependency edge (the snapshot selects from the upstream via ref, or the build order enforces it) and run the affected subgraph in order: upstream first, snapshot second.

agent reordered models in the dag and broke the snapshot dependency

Use this when

• a snapshot captured stale data or failed right after DAG or scheduling changes
• the snapshot upstream model builds later than the snapshot in the same job
• the snapshot SQL reads the upstream table directly by name instead of via ref, so dbt never learned the dependency

Not for this skill when

• the snapshot depends only on sources, ordering against models is irrelevant; look at source load timing instead
• upstream data itself is wrong, snapshot ordering is fine and the bug is in the upstream model
• you intentionally snapshot pre-model raw state, document that design and protect it from helpful reordering

Steps

1. Check the dependency: open the snapshot definition and confirm it selects from the upstream model with ref (not a hardcoded table name), then view the DAG (dbt ls or docs lineage) for the edge between them. Verify: the snapshot either has the ref edge or its absence is confirmed as the defect.

2. Fix the edge: replace hardcoded relation references in the snapshot with ref to the upstream model, or if the read must stay direct, enforce order in the orchestrator by splitting steps (build upstream models, then run snapshots). Verify: a real dependency edge or an enforced step order exists.

3. Check the job structure: a single dbt build handles ordering automatically once the edge exists; separate run and snapshot commands must be sequenced upstream first. Verify: the job commands run in dependency order.

4. Execute the subgraph in order with dbt build --select using the upstream model with a trailing plus to include downstream (or the snapshot plus sign prefix for parents) and inspect the snapshot result timestamps versus the upstream build. Verify: upstream builds first and the snapshot captures its fresh output.

Variant phrasings

reorder was in the orchestrator, not dbt

Airflow-style task reordering can defeat a correct DAG if snapshot tasks were split out. Keep snapshot tasks downstream of model tasks in the orchestrator graph too.

snapshot depends on an ephemeral model

Ephemeral upstreams complicate snapshot reads because no table exists. Materialize the upstream as a view or table if a snapshot must consume it.

Compatibility: dbt-core DAG ordering via ref dependencies; dbt build executes in topological order. Snapshots defined in .sql snapshot blocks or YAML on supported versions.

Why it happens

dbt orders work from the dependency graph it can see, and it can only see dependencies expressed as ref and source calls. Hardcoded table names, or an orchestrator that runs snapshots as a separate earlier step, hide the edge, so the snapshot faithfully captures whatever the upstream table held at that moment: the previous run output. The data looks one cycle stale because, mechanically, it is.

Edge cases / pitfalls

• A stale-by-one-cycle snapshot closes and opens records a day late, which point-in-time queries surface as wrong history; backfill decisions belong with the data owner.
• Renaming the upstream model without updating the snapshot ref recreates this class of bug as a compile error instead, which is the luckier outcome.
• After fixing order, compare snapshot dbtupdatedat values against upstream build times for a few cycles to confirm the lag is gone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DzJPoTzgDy--1nZjUt-TIA