Skip to content

Cube materialization retention - #2558

Draft
shangyian wants to merge 1 commit into
mainfrom
cube-retention-dropped
Draft

shangyian wants to merge 1 commit into
mainfrom
cube-retention-dropped

Conversation

@shangyian

Copy link
Copy Markdown
Collaborator

No description provided.

@netlify

netlify Bot commented Sep 20, 2026

Copy link
Copy Markdown

Deploy Preview for thriving-cassata-78ae72 canceled.

Name Link
🔨 Latest commit 905829f
🔍 Latest deploy log https://app.netlify.com/projects/thriving-cassata-78ae72/deploys/6aaffdfddd098e00088352f5

@shangyian shangyian changed the title Carry a cube's declared retention into its materialization Cube materialization retention Sep 20, 2026
`MaterializationSpec.retention` was read on export but never written. #2403
wired the field through the API path, the config builder and the job that
consumes it, but not through `internal/materializations.py`, so a block
declared in YAML reached `UpsertCubeMaterialization` without it and the
upsert took the field default. The stored config held 400 DAYS whatever the
author asked for.

Two things followed. The cube was materialized with a retention nobody
declared, which for a block covering years of history means Druid dropping
data the cube is supposed to serve. And because the export reads retention
back out of that config, a cube declaring anything else compared unequal to
its own YAML on every deploy -- reported as an update, rescheduled, forever.

All three places that build an upsert dropped it: the initial build, the
revision-swap rebuild, and `_upsert_from_materialization`, which recovers
intent from a stored row. That last one loses retention with no YAML change
involved at all -- a cube materialized correctly reverts to the default on
its next revision swap -- so it reads the stored value with the same default
the export uses, and a config predating the field rebuilds as export already
reports it.

The deployment test asserts the round trip rather than the stored value,
since it is export-equals-declaration that the comparison depends on.

Existing rows keep the retention they were built with, so the first deploy
after this lands is a real update for any cube that declared another value.
@shangyian
shangyian force-pushed the cube-retention-dropped branch from 2fe30aa to 905829f Compare September 20, 2026 15:38
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