Conversation
toProviderResolutionDetail mapped FlagNotFoundCode to DefaultReason and TargetingKeyMissingCode to TargetingMatchReason, reporting success reasons for error codes. Per spec requirement 1.4.9, abnormal execution SHOULD set reason to indicate an error. Map both to ErrorReason, consistent with the other error codes in the switch. Closes open-feature#560 Signed-off-by: Vladimir Babin <vovababin@gmail.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe change maps ChangesResolution error reason mapping
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix · Severity of issue fixed: Low Suggested reviewers: Merge Risk: ⚪ Minimal · up to The targeted error-reason mappings and regression coverage align with the intended behavior, so the change is ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Comment |
Closes #560.
Problem
In
openfeature/multi/isolation.go,toProviderResolutionDetailmaps two error codes to reasons that assert success:FlagNotFoundCode→of.DefaultReasonTargetingKeyMissingCode→of.TargetingMatchReason(a targeting match reported as the reason for a missing targeting key)Every other error code in the switch maps to
of.ErrorReason.Fix
Map both to
of.ErrorReason. Per spec requirement 1.4.9, in cases of abnormal execution thereasonfield SHOULD indicate an error.Tests
Added
Test_toProviderResolutionDetail_ErrorCodesMapToErrorReason— a table test asserting every error code producesErrorReasonand a non-nilError().Validation:
Confirmed RED before the fix (the
flag not foundandtargeting key missingsubtests failed withexpected: "ERROR") and GREEN after.