When a cube's definition changes materially (e.g., dimensions swapped, metrics added/removed/changed), a new cube revision is created. Today the previous revision's materialization workflow keeps running and keeps posting fresh table availability back to DJ. That stale-but-live availability record then gets used to route queries against the new revision, producing column-not-found errors.
On a non-trivial cube revision, we should stop/disable the materialization workflow tied to the prior revision so it stops posting availability. Define "non-trivial" as: change to the set of metric components (including component expression hashes), the dimension set, or the filters.
When a cube's definition changes materially (e.g., dimensions swapped, metrics added/removed/changed), a new cube revision is created. Today the previous revision's materialization workflow keeps running and keeps posting fresh table availability back to DJ. That stale-but-live availability record then gets used to route queries against the new revision, producing column-not-found errors.
On a non-trivial cube revision, we should stop/disable the materialization workflow tied to the prior revision so it stops posting availability. Define "non-trivial" as: change to the set of metric components (including component expression hashes), the dimension set, or the filters.