Repository navigation
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughFeature evaluation now assigns Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Severity of issue fixed: Low Merge Risk: ⚪ Minimal · up to The fallback reasons align with the requested STATIC versus DEFAULT distinction. The test-data revision discrepancy does not change fixture contents; this change is mergeable subject to normal checks. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 2 systems. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Advanced
Run ID: 51341f3c-fda6-4137-8c93-7e7e4d96bded
📒 Files selected for processing (2)
flag_engine/segments/evaluator.pytests/unit/test_engine.py
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against fdf0448 |
| def test_get_evaluation_result__unmatched_segment_override__returns_default_reason( | ||
| context: EvaluationContext, | ||
| ) -> None: | ||
| # Given | ||
| context["segments"] = { | ||
| "1": { | ||
| "key": "1", | ||
| "name": "unmatched_segment", | ||
| "rules": [ | ||
| { | ||
| "type": "ALL", | ||
| "conditions": [ | ||
| {"property": "foo", "operator": "EQUAL", "value": "no match"} | ||
| ], | ||
| } | ||
| ], | ||
| "overrides": [ | ||
| { | ||
| "key": "4", | ||
| "name": "feature_1", | ||
| "enabled": False, | ||
| "value": "segment_override", | ||
| } | ||
| ], | ||
| } | ||
| } | ||
|
|
||
| # When | ||
| result = get_evaluation_result(context) | ||
|
|
||
| # Then | ||
| assert result["flags"]["feature_1"]["reason"] == "DEFAULT" | ||
| assert result["flags"]["feature_2"]["reason"] == "STATIC" |
There was a problem hiding this comment.
Remove this; engine-test-data covers it.
There was a problem hiding this comment.
| """ | ||
| Get the reason for a flag evaluated to its environment default. | ||
|
|
||
| `DEFAULT` if the feature has targeting rules that did not match, |
There was a problem hiding this comment.
DEFAULTif the feature has targeting rules that did not match,
@matthewelwell is this the behaviour we're looking for? I was under the impression that we'd decided to reserve DEFAULT for SDK-side defaults?
There was a problem hiding this comment.
The implementation is correct (I checked the issue body with @aepfli back in September)
There was a problem hiding this comment.
In that case, we need another PR to engine-test-data adding a test case for DEFAULT.
Closes #341
When a flag falls back to its environment default, the engine always returned the DEFAULT reason.
Now: