feat: Add the override marker to the flag and segment models and mark evaluations - #221
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 The OVERRIDE specification requires an evaluation to be marked as override-affected when any definition it read carried the override 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's own record reflects only the definitions that its own subtree read. An evaluation that fails is still marked when it read a marked definition. DataModel.FeatureFlag and DataModel.Segment carry a transient isOverride marker that is never serialized and never read from JSON, with a markedAsOverride() shallow copy that the override layer will use without modifying the source's entity. The evaluator tracks the marking per evaluation scope: the scope starts from its own flag's marker, each segment read can set it, and the value is saved, reset to the prerequisite's marker, and restored around each prerequisite evaluation. The result and every prerequisite record carry the marking on their reason. EvalResult exposes isOverrideAffected() and withOverrideAffected(), which copies rather than mutating the shared precomputed results. A requested-type mismatch keeps the marking on its error reason. The server SDK now depends on launchdarkly-java-sdk-common 2.6.0, which adds the overrideAffected indicator to EvaluationReason. CI for this change cannot pass until that version is released. Flag overrides are currently experimental and subject to change.
kinyoklion
force-pushed
the
rlamb/overrides-java-filedata-reloader
branch
from
September 28, 2026 21:03
f0038ed to
79250a7
Compare
kinyoklion
force-pushed
the
rlamb/overrides-java-model-marker
branch
from
September 28, 2026 21:03
39b0b95 to
d82beda
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
1 participant
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
The OVERRIDE specification requires an evaluation to be marked as override-affected when any definition it read carried the override 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's own record reflects only the definitions that its own subtree read, while the evaluation that requested it accumulates the result. An evaluation that fails is still marked when it read a marked definition, and a requested-type mismatch keeps the marking on its error reason.
DataModel.FeatureFlagandDataModel.Segmentcarry a transientisOverridemarker. It is never serialized and never read from JSON.markedAsOverride()returns a shallow copy with the marker set, sharing nested collections and preprocessing with the source and never modifying it. The override layer will use it in the next change.EvalResult.isOverrideAffected()reads the reason's indicator, andwithOverrideAffected(boolean)returns a copy so that the shared precomputed results are never mutated.EvaluationReason.isOverrideAffected()and theoverrideAffectedJSON property (written only when true). CI for this change cannot pass until that version is released.Flag overrides are currently experimental and subject to change.
This PR is based on the file data reliability branch (rlamb/overrides-java-filedata-reloader) so the series applies in order; retarget it to feat/overrides once that branch merges.
The existing file data source keeps its current behavior; this change does not touch its code paths.