Problem
When an environment document returned by the Flagsmith API contains more than one entry in identity_overrides sharing the same identifier, the SDK keeps only the last entry for that identifier during local evaluation. Any identity_features defined on the earlier entries are discarded, so the corresponding flags fall back to the environment default instead of the configured override.
For example, given an environment payload like:
{
"identity_overrides": [
{
"identifier": "multi-override-id",
"identity_features": [
{
"feature": { "name": "some_feature" },
"feature_state_value": "override-from-first-entry",
"enabled": false
}
]
},
{
"identifier": "multi-override-id",
"identity_features": [
{
"feature": { "name": "mv_feature" },
"feature_state_value": "override-from-second-entry",
"enabled": true
}
]
}
]
}
Calling getIdentityFlags('multi-override-id') with local evaluation enabled returns the override for mv_feature only. some_feature resolves to its environment default, as if the first entry never existed.
Impact
Any identifier whose overrides arrive split across multiple identity_overrides entries gets the wrong flag values during server-side local evaluation. The breakage is silent (no warning, no error) and deterministic for a given payload, so affected identifiers stay broken on every request until the environment payload changes shape.
Reproduction
- Use an environment whose
identity_overrides array contains two entries with the same identifier, each carrying a different feature in identity_features (e.g. entry A overrides some_feature, entry B overrides mv_feature).
- Initialise the SDK with
enableLocalEvaluation: true and call getIdentityFlags('<that-identifier>').
- Observed: only the features from the last entry are applied.
some_feature resolves to its environment default instead of "override-from-first-entry".
- Expected: both
some_feature and mv_feature resolve to their respective override values and enabled states.
Problem
When an environment document returned by the Flagsmith API contains more than one entry in
identity_overridessharing the sameidentifier, the SDK keeps only the last entry for that identifier during local evaluation. Anyidentity_featuresdefined on the earlier entries are discarded, so the corresponding flags fall back to the environment default instead of the configured override.For example, given an environment payload like:
{ "identity_overrides": [ { "identifier": "multi-override-id", "identity_features": [ { "feature": { "name": "some_feature" }, "feature_state_value": "override-from-first-entry", "enabled": false } ] }, { "identifier": "multi-override-id", "identity_features": [ { "feature": { "name": "mv_feature" }, "feature_state_value": "override-from-second-entry", "enabled": true } ] } ] }Calling
getIdentityFlags('multi-override-id')with local evaluation enabled returns the override formv_featureonly.some_featureresolves to its environment default, as if the first entry never existed.Impact
Any identifier whose overrides arrive split across multiple
identity_overridesentries gets the wrong flag values during server-side local evaluation. The breakage is silent (no warning, no error) and deterministic for a given payload, so affected identifiers stay broken on every request until the environment payload changes shape.Reproduction
identity_overridesarray contains two entries with the sameidentifier, each carrying a different feature inidentity_features(e.g. entry A overridessome_feature, entry B overridesmv_feature).enableLocalEvaluation: trueand callgetIdentityFlags('<that-identifier>').some_featureresolves to its environment default instead of"override-from-first-entry".some_featureandmv_featureresolve to their respective override values and enabled states.