test: make remaining incremental functional tests rerun-safe - #1512
Merged
sd-db merged 2 commits intoJun 15, 2026
Conversation
Apply RerunSafeMixin to the incremental functional tests that rewrite schema.yml or model files mid-test (tags, column tags, tblproperties, liquid clustering, column masks, persist_docs, replace table), so a pytest --reruns retry no longer inherits mutated files and half-built relations from the failed attempt. Follows the pattern established for the incremental constraint tests and column-tag tests. Co-authored-by: Isaac
Coverage report
This PR does not seem to contain any modification to coverable code. |
Collaborator
|
/integration-test |
|
Integration tests dispatched for PR #1512 by @sd-db. Track progress in the Actions tab. |
sd-db
approved these changes
Jun 15, 2026
sd-db
left a comment
sd-db
left a comment
Collaborator
There was a problem hiding this comment.
Changes look good, thanks for the PR ! Started the integration test run, will merge once all green !!
|
Integration results for PR #1512 — UC cluster ✅ success · SQL warehouse ✅ success · All-purpose cluster ✅ success · Shard coverage ✅ success |
sd-db
added a commit
that referenced
this pull request
Jun 17, 2026
…le change (#1522) ## What Adds functional coverage asserting that an **updateable-component** change to a materialized view — `databricks_tags` or the refresh `schedule` — is applied via an **in-place `ALTER`** and does **not** rebuild the MV. This is the `requires_full_refresh=False` branch of `MaterializedViewConfig.get_changeset` (`updateable_component_keys = ["refresh", "tags", "row_filter"]`). ## Why The existing suite proves this branch only via debug-log substrings (`assert_message_in_logs("Applying ALTER" / "Applying REPLACE")`), which is not server-observable, and the unit test (`test_get_changeset__some_changes`) pins only the `requires_full_refresh=True` case. So "an updateable change does not rebuild the MV" had no server-side coverage. ## How it's proven Source-row staleness: a row is inserted into the source **after** the MV is materialized. The test confirms the row landed in the source (`count == 3`) yet the MV stays at `2` across each change — an in-place `ALTER` neither recomputes the query nor issues a `REFRESH`, whereas a `CREATE OR REPLACE` (the misclassification this guards against) would pull the new row in. One class walks a single MV through a tags change, then a refresh-schedule change. To keep the staleness assertion sound, the MV starts `MANUAL` (no schedule) and the refresh step moves it to `EVERY 4 WEEKS`, so the server never auto-refreshes it during the run. ## Testing `pytest tests/functional/adapter/materialized_view_tests/test_mv_alter_no_rebuild.py` → **1 passed** (profile `databricks_uc_sql_endpoint`). Section collects cleanly; `ruff` / `ruff format` / `mypy` pass. Test-only change — no changelog entry, consistent with #1511 / #1512 / #1514.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Follow-up to #1503 (incremental constraint tests) and #1499 (column-tag tests): applies the same
RerunSafeMixintreatment to the remaining incremental functional tests that mutate on-disk state mid-test.These tests rewrite
schema.yml(ormodel.sql) viawrite_fileand build relations during the test body. Underpytest --reruns 2(used in CI integration runs), a transient failure leaves the retry running against the mutated files and the half-built relation from the failed attempt, so the retry fails deterministically and the rerun budget is wasted.Covered files:
test_incremental_tags.py(SQL + Python)test_incremental_column_tags.py(SQL + Python)test_incremental_tblproperties.py(SQL + Python)test_incremental_clustering.py(SQL + Python)test_incremental_column_masks.py(incl. DescribeJsonOn subclass via inheritance)test_incremental_persist_docs.py(incl. V2 subclass via inheritance)test_incremental_replace_table.pyTest-only change, no runtime impact.
Verified against a UC SQL warehouse and a UC all-purpose cluster: 11 passed. The two
column_tagstests could not run in my workspace because a Unity Catalog tag policy there restricts allowed values for thepiitag key (the fixtures usepii: "false"); the unmodified tests fail identically on that workspace, so this is environmental and unrelated to the change. They are covered by the CI integration environment.Checklist
CHANGELOG.mdand added information about my change to the "dbt-databricks next" section.