Repository navigation
feat: Add the override marker to the model, evaluator, and reason - #450
Draft
kinyoklion wants to merge 1 commit into
Draft
kinyoklion wants to merge 1 commit into
kinyoklion wants to merge 1 commit into
Conversation
kinyoklion
force-pushed
the
rlamb/overrides-ruby-model-evaluator
branch
from
September 25, 2026 22:51
0f89736 to
4810ac9
Compare
kinyoklion
force-pushed
the
rlamb/overrides-ruby-filedata
branch
from
September 28, 2026 20:36
eb26dd7 to
72d5776
Compare
kinyoklion
force-pushed
the
rlamb/overrides-ruby-model-evaluator
branch
3 times, most recently
from
October 3, 2026 00:46
8072ee4 to
ed8fccf
Compare
Member
Author
|
bugbot review |
There was a problem hiding this comment.
✅ 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 ed8fccf. Configure here.
kinyoklion
force-pushed
the
rlamb/overrides-ruby-model-evaluator
branch
from
October 3, 2026 01:54
ed8fccf to
bb04f10
Compare
Flag overrides, as defined by the OVERRIDE specification, need three pieces below the store: a marker on the flag and segment model that says a definition came from the override store, evaluator marking that follows every definition an evaluation reads, and an indicator on the evaluation reason that reports the marking to callers. The model classes carry the marker as an attribute that is never serialized. `as_override` returns a marked shallow copy and leaves the original unchanged. Only the SDK components that manage override entries set it. The evaluator marks an evaluation as override-affected when the evaluated flag, a prerequisite flag at any depth, or a segment read during clause matching carries the marker. A segment counts when it is read, so a segment that does not match, or that is read through a negated clause, still marks the evaluation. The marking propagates upward only: a prerequisite's own record reflects the definitions its own subtree read, and a plain prerequisite inside a marked evaluation is not marked. An error result is marked when a marked definition was read before the failure, including when the failure was raised while a prerequisite was being evaluated. An evaluation that reads no marked definition keeps the shared precomputed detail instances. `EvaluationReason#override_affected` carries the indicator. It is written to JSON as `overrideAffected` only when true, so the wire format of ordinary evaluations is unchanged. `with_override_affected` follows the `with_big_segments_status` precedent and returns the same instance when nothing changes. Flag overrides are currently experimental and subject to change.
kinyoklion
force-pushed
the
rlamb/overrides-ruby-model-evaluator
branch
from
October 8, 2026 16:54
bb04f10 to
6ad2419
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
This PR is stacked on #449 so that the flag overrides series applies in order. It does not use that PR's code.
Flag overrides, as defined by the OVERRIDE specification, need three pieces below the store: a marker on the flag and segment model that says a definition came from the override store, evaluator marking that follows every definition an evaluation reads, and an indicator on the evaluation reason that reports the marking to callers. This change adds those three pieces. Nothing sets the marker yet, so the SDK behaves exactly as before. The override store, the overlay, and the data system wiring follow in the next PR.
The model classes
FeatureFlagandSegmentcarry the marker as an attribute that is never serialized, becauseas_jsonreturns the flag data hash.as_overridereturns a marked shallow copy and leaves the original unchanged. Only the SDK components that manage override entries will set it.The evaluator marks an evaluation as override-affected when the evaluated flag, a prerequisite flag at any depth, or a segment read during clause matching carries the marker. A segment counts when it is read, so a segment that does not match, or one read through a negated clause, still marks the evaluation. The marking propagates upward only. A prerequisite's own record reflects the definitions its own subtree read, so a plain prerequisite inside a marked evaluation is recorded as usual, and a prerequisite of an overridden flag is not marked by its parent. An error result is marked when a marked definition was read before the failure, including a failure raised while a prerequisite was being evaluated. An evaluation that reads no marked definition keeps the shared precomputed detail instances.
EvaluationReason#override_affectedcarries the indicator, following theinExperimentandbigSegmentsStatusprecedents. It is written to JSON asoverrideAffectedonly when true, so the wire format of ordinary evaluations is unchanged.with_override_affectedreturns the same instance when nothing changes, andwith_big_segments_statuskeeps the indicator.Verification: specs for the model marker (default, copy, original unchanged, not serialized), the reason indicator (default, JSON when true and when false,
[], equality, interaction with the big segments status), and the evaluator marking rules (direct, prerequisite at any depth, upward-only propagation, unaffected prerequisite record, segment read with and without a match, negated clause, nested segment, unresolved definition, prerequisite failure, malformed override, error raised during a prerequisite evaluation, big segments status kept). Full suite and RuboCop are clean. Each new spec was checked against a deliberate defect in the code it covers.The existing FDv1 and FDv2 file data sources keep their current behavior. This series does not change them; the override feature is additive.
SDK-3249
Note
Overview
Adds experimental flag-override plumbing so evaluations can report when override-store definitions influenced the result, without wiring the override store yet (nothing calls
as_overridein production code, so default behavior stays the same).Model:
FeatureFlagandSegmentget a non-serialized override marker viaoverride?andas_override(shallow copy).Evaluator: Tracks
override_affectedon state andEvalResult, sets it when the evaluated flag, any prerequisite subtree, or any segment read during matching is marked; prerequisite records carry their own subtree marking with upward-only propagation. Unaffected evaluations still reuse shared precomputedEvaluationDetailinstances.Reason:
EvaluationReason#override_affectedandwith_override_affected; JSON addsoverrideAffectedonly when true.Specs cover marker serialization, reason JSON/equality, and evaluator propagation edge cases (negated segments, errors, big segments).
Reviewed by Cursor Bugbot for commit ed8fccf. Bugbot is set up for automated code reviews on this repo. Configure here.