[kinyoklion]

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, as does the WRONG_TYPE error that migrationVariation returns for an unrecognized stage.

• DataModel.FeatureFlag and DataModel.Segment carry a transient isOverride marker. 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.
• 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 own marker, and restored around every prerequisite evaluation. Each result and each prerequisite record carries the marking on its reason.
• EvalResult.isOverrideAffected() reads the reason's indicator, and withOverrideAffected(boolean) returns a copy so that the shared precomputed results are never mutated.
• An evaluation that throws returns an EXCEPTION result marked with the evaluated flag's own marker, because that definition was read before the failure.
• The server SDK now depends on launchdarkly-java-sdk-common 2.6.0, which adds EvaluationReason.isOverrideAffected() and the overrideAffected JSON 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.

SDK-3246

---

Note

Overview
Adds experimental override tracking so evaluations can report when they used SDK-local flag or segment definitions instead of LaunchDarkly data.

Data model: FeatureFlag and Segment get a transient isOverride flag (not in JSON) plus markedAsOverride() shallow copies for the future override layer. Dependency: launchdarkly-java-sdk-common is bumped to 2.6.0 for EvaluationReason.isOverrideAffected() / serialization.

Evaluation: The evaluator accumulates override-affected state from the evaluated flag, prerequisite subtrees (scoped per prereq, upward propagation only), and any segment read during matching—even on non-match or errors. Results expose EvalResult.isOverrideAffected() and withOverrideAffected() without mutating shared precomputed instances. Wrappers (InputValidatingEvaluator, MigrationStageEnforcingEvaluator) preserve marking on type errors, exceptions, and allFlagsState reasons.

^{Reviewed by Cursor Bugbot for commit 64740d7. Bugbot is set up for automated code reviews on this repo. Configure here.}

_{Opened from termag}

[kinyoklion]

bugbot review

[cursor]

Stale Bugbot comment from a previous run.

[kinyoklion]

bugbot review

[cursor]

Stale Bugbot comment from a previous run.

[kinyoklion]

bugbot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 64740d7. Configure here.}