Scope the step-down publish boundary by the table's creation era

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Storage Engines - Foundations
    • 99.053
    • None
    • None

      The publish check for the step-down disaggregated schema epoch rejects any publish at or below the boundary, for every table. A table created before the boundary was declared can only reach the step-down checkpoint through an epoch at or below the boundary, so once the boundary is set there is no epoch that puts it there: publishing at or below is refused and publishing above defers the table to the next leader era. If the table holds stable data, the step-down checkpoint later fails with "stable data checkpointed for unpublished table"; if it is empty, it is silently excluded and leaves a stale queue entry behind.

      The intended contract partitions the epoch space by the era the table was created in:

      • A table created before the boundary must be published at or below it, so the step-down checkpoint carries it.
      • A table created inside the step-down window has no stable constituent, belongs to the next era, and must be published above the boundary.

      Scope the publish check by era, using the queue entry's missing stable constituent to recognize a window create. A drop always enqueues without a stable value, so a queued drop classifies as next-era and is deferred past the step-down checkpoint, which is the safe direction: the table survives one era longer rather than being dropped early.

            Assignee:
            Jie Chen
            Reporter:
            Jie Chen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: