fix(numbering): a materializing partition inherits the base row's counter, not zero (#6517) - #6518
Merged
Merged
Conversation
…nter, not zero (#6517) On a fresh tenant with a partitioned series the operator seeded prefix + next on the base row (the only row that exists before the first allocation) - and the first issued document rendered ...0000000001: the prefix took effect, the counter did not. materializePartition copied only the shape and hardcoded the counter to zero, silently discarding the seed. The base row is the tenant's full template now: a partition row is born with the base shape AND the base counter, so seeding before first use works; the settings page's virtual rows preview the inherited value and the base-row hint says "inheriting this shape and its starting counter". Declared-series provisioning still starts at zero, and existing partition rows are untouched. NumberingSdkIT: seed base next=300, first allocation of a brand-new partition renders exactly T-0300 and continues (3 numbering ITs green locally). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
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.
Closes #6517.
Live failure: on a freshly provisioned tenant with a
per:-partitioned series, the operator seeded prefix + Next=178 on the base row (before the first allocation nothing marks the series partitioned, so the base row is the only editable row) — the first issued document rendered0000000001.materializePartitioncopied only the shape from the base row and hardcoded the counter to 0, silently discarding the seed..numbersprovisioning of a declared series still starts the base at zero, and already-materialized partition rows are untouched.next = base + 1) instead of a hardcoded 1, and the base-row hint copy now reads "…inheriting this shape and its starting counter" (en + bg).Test:
NumberingSdkIT.aFreshPartitionInheritsTheBaseRowsSeededCounter— seed base Next=300, the first allocation of a brand-new partition renders exactlyT-0300and continues withT-0301. All three numbering ITs green locally.Runtime-only (engine + settings page) — no regeneration needed; a platform rebuild picks it up.
🤖 Generated with Claude Code