Skip to content

fix: recreate relations missing from the warehouse snapshot - #818

Merged
kvlonge merged 4 commits into
mainfrom
fix/missing-relation-first-run
Sep 25, 2026
Merged

kvlonge merged 4 commits into
mainfrom
fix/missing-relation-first-run

Conversation

@kvlonge

@kvlonge kvlonge commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

Why

A relation dropped outside SQLBuild still planned as already built when its fingerprint remained. Incremental execution then failed against the missing table. The warehouse snapshot must determine live existence; stored records describe history.

Changes

  • Plan absent relations as first runs regardless of fingerprints, clear previous built identity, and emit RECORDED_RELATION_MISSING when historical state exists.
  • Preserve verified migration rename handover so downstream history is not replayed unnecessarily.
  • Correct missing-seed plan reasons and allow microbatch full refresh to create an absent target.
  • Add source-of-truth architecture guidance to AGENTS.md.

Verification

  • Focused planner, migration, output, executor and CLI regressions pass, including dropped incremental, snapshot, table, view, seed and sequential/concurrent microbatch cases.
  • uv sync --all-extras and make check-ci pass; public-content scan and diff checks pass.
  • Independent read-only review found no correctness or regression blockers.

A model whose relation was dropped outside SQLBuild was still planned as
built because a stored fingerprint existed: incremental models kept their
cursor bounds and failed on the missing table, and views and tables reported
no_change. Change detection now treats the warehouse snapshot as the source of
truth for relation existence and consults stored fingerprints only when the
relation exists.

- Plan a first run for any model whose relation is absent, regardless of
  stored fingerprints, and emit a RECORDED_RELATION_MISSING plan warning when
  stored state recorded a previous build.
- Report the built version as missing in plan JSON and expose warning codes.
- Plan a seed whose relation is absent as a first run.
- Let microbatch full-refresh builds create an absent live target instead of
  failing reconciliation.
…first-run

# Conflicts:
#	tests/e2e/src/sqlbuild/cli/commands/main/build/_test_types.py
After integrating model migrations, the unconditional missing-relation first
run preceded the RENAMED branch, so a verified rename whose destination is
intentionally not created yet planned as a first run, emitted a spurious
RECORDED_RELATION_MISSING warning, and replayed downstream history. Check the
migration-verified rename before treating a missing relation as a first run.
@kvlonge
kvlonge enabled auto-merge (squash) September 25, 2026 06:26
@kvlonge
kvlonge merged commit 19b42fd into main Sep 25, 2026
28 checks passed
@kvlonge
kvlonge deleted the fix/missing-relation-first-run branch September 25, 2026 06:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant