feat: preserve populations through maintenance row operations - #672
Merged
Merged
Conversation
…ped-rows # Conflicts: # data_plane/src/precompute_engine/maintenance_runtime.rs
zzylol
changed the base branch from
feat/maintenance-population-inventory
to
main
September 11, 2026 19:48
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.
Why
A maintenance expression must retain population identity while combining finalized values. Flattening groups before a binary operation can mix independent series at the same timestamp.
What
Preserve the existing typed group map through private summary windows and finalized rows. Keep the current singleton execution gate.
How
Binary arithmetic first requires identical complete group sets, then performs the existing strict timestamp join within each group. Summary merge rejects different groups. An explicit summary update projects output grouping and rejects multiple output populations before updating state.
Before this PR
Finalized rows carried timestamps and values but no population identity.
After this PR
Two groups sharing a timestamp remain separate through subtraction: a:5 minus a:2 yields a:3; b:9 minus b:4 yields b:5. Missing groups reject instead of producing a partial result.
Verification
Limits
This private representation does not enable multi-population scheduling. The future complete-cohort consumer must bind the computed output group to persisted labels and publish one complete outer result transactionally. Canonical routing, continuous completion, and sliding execution remain separate.
Stacked on #670.