Repository navigation
fix: Serve multivariate segment overrides their variant under local evaluation - #128
Conversation
…valuation Segment overrides were mapped without their multivariate values, so every identity in the segment got the override's control value. Map them the same way as environment features.
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
 |
🤖 I have created a release *beep* *boop* --- ## [5.2.0](v5.1.0...v5.2.0) (2026-11-09) ### Features * Support `getExperimentFlag`, `trackEvent` and `trackExposure` methods ([#127](#127)) ([670b413](670b413)) ### Bug Fixes * Serve multivariate segment overrides their variant under local evaluation ([#128](#128)) ([dbb7a83](dbb7a83)) ### Other * Let Renovate keep updating spec bumps the webhook handler commits to ([#123](#123)) ([a6ccd7f](a6ccd7f)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Under local evaluation, a segment override with a multivariate split served every identity in the segment the override's control value. No identity ever got a variant. This affects every experiment, since an experiment's rollout is a segment override.
Cause
The segment mapper built overrides without their
multivariate_feature_state_values. The environment mapper maps them for environment features, but the segment mapper had its own copy that didn't.Changes
Environment.build_feature_hash, the same function as environment features, so the two can't drift apart again.Why tests didn't catch it
engine-test-data feeds the engine a ready-made evaluation context, so it never runs the SDK's mapper from the environment document.