feat: Add the override marker to the flag and segment models and mark evaluations - #363
Draft
kinyoklion wants to merge 1 commit into
Draft
kinyoklion wants to merge 1 commit into
kinyoklion wants to merge 1 commit into
Conversation
… evaluations FeatureFlag and Segment gain an internal IsOverride marker and an AsOverride method that returns a marked copy sharing the immutable parts of the original. The marker lives on the model only and is never serialized. The evaluator marks an evaluation as override-affected when any definition it read carried the marker: the evaluated flag, a prerequisite at any depth, or a segment consulted during matching, whether or not the segment matched. The marking propagates upward only: a prerequisite record reflects only the definitions its own subtree read. Error results are marked too. The result is reported through the evaluation reason's OverrideAffected indicator, as defined by the OVERRIDE specification.
kinyoklion
force-pushed
the
rlamb/overrides-dotnet-reason-marker
branch
from
September 28, 2026 20:39
e4dfcf4 to
74be7f9
Compare
kinyoklion
force-pushed
the
rlamb/overrides-dotnet-model-evaluator
branch
from
September 28, 2026 20:39
aff3a67 to
ae86267
Compare
This branch has not been deployed
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.
Summary
Adds the override marker to the flag and segment models and makes the evaluator mark evaluations as override-affected, as defined by the OVERRIDE specification.
FeatureFlagandSegmentgain an internalIsOverrideproperty and anAsOverride()method that returns a marked copy sharing the immutable parts of the original. The marker lives on the model only: the JSON converters do not write it, so a marked definition serializes exactly like an unmarked one, and the original object handed toAsOverride()is never modified.The evaluator marks an evaluation when any definition it read carried the marker: the evaluated flag, a prerequisite flag at any depth, or a segment consulted during clause matching, whether or not the segment matched. The marking propagates upward only. Each prerequisite evaluation is a scope of its own that starts from the prerequisite's marker, so the record for a prerequisite reflects only its own subtree, while the parent scope absorbs the nested marking when the nested evaluation returns or throws. Error results are marked too: a malformed override flag, a prerequisite cycle through an override flag, and an invalid context all produce an error reason that carries the indicator. A definition that cannot be resolved contributes nothing. The marking is reported through the reason's
OverrideAffectedindicator from the previous change in this series.Nothing in this change produces marked definitions yet; the override store that does so is the next change. Every existing evaluation therefore behaves as before, which the existing evaluator tests confirm. The new tests cover each marking case, including the prerequisite tree in the specification where only one leaf is overridden.
This PR is based on the branch of the EvaluationReason indicator change, which it depends on.