Scope availability posting to the node revision it was built for#2362
Merged
shangyian merged 1 commit intoJul 24, 2026
Merged
Conversation
✅ Deploy Preview for thriving-cassata-78ae72 canceled.
|
shangyian
changed the title
shangyian
force-pushed
the
fix-stale-availability-version-guard
branch
from
July 24, 2026 00:24
006c2cb to
81e06d5
Compare
…lt for
POST /data/{node}/availability binds availability to node.current
unconditionally. A materialization workflow left running after a non-trivial
redefinition (e.g. a cube whose dimensions/metrics changed) keeps posting for a
superseded revision, stamping a stale, schema-mismatched table onto the new
revision so queries resolve to the wrong table.
Scope the availability to the revision it was produced for. The target version
is an explicit node_version if a producer sends one, else it is derived from the
materialized table name, which already encodes <node>_<version>_<hash> (factored
into a shared materialized_table_name / version_from_materialized_table pair so
build and parse can't drift). The availability attaches to that revision — an
older revision keeps its own availability (valid for pinned queries) while the
current revision is left untouched. An explicit unknown version is rejected; a
derived version matching no revision falls back to the current revision.
Because the version is derived from the table name producers already send, this
works with existing materialization workflows without a client change.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
shangyian
force-pushed
the
fix-stale-availability-version-guard
branch
from
July 24, 2026 08:59
81e06d5 to
09fd41a
Compare
shangyian
marked this pull request as ready for review
July 24, 2026 09:32
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
1 participant
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.
Summary
Calling
POST /data/{node}/availabilityalways attaches the reported availability to the node's current revision. When a node is redefined in a non-trivial way (e.g. a cube whose dimensions or metrics change), a materialization workflow that was running against the previous revision keeps posting availability and that post lands on the new current revision, which is wrong. The reported table was built from the old definition, so its physical columns don't match what the new revision generates, and queries against the current revision resolve to a stale, schema-mismatched table and fail at execution.Availability is already revision-scoped in the db schema (
nodeavailabilitystate.node_idtonoderevision.id), so the bug is that the write path ignores which revision produced the data.The fix is to attach availability to the revision it was actually produced for. The target version is resolved in order:
node_versionon the request, if the producer sends one<node>_<version>_<hash>(e.g.dj__foo_bar_v1_0_ab12…)The availability then attaches to that revision. An older revision keeps its own availability (still valid for version-pinned queries) while the current revision is left untouched, so its queries fall back correctly instead of hitting a mismatched table.
Because the version is derived from the table name producers already send, this fixes the case for existing materialization workflows with no client-side change.
node_versionis an optional, forward-looking override.Test Plan
make checkpassesmake testshows 100% unit test coverageDeployment Plan