Skip to content

[sdk/local-evaluation] Duplicate identity override entries silently drop feature overrides #267

@xolott-ark

Description

@xolott-ark

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

  1. 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).
  2. Initialise the SDK with enableLocalEvaluation: true and call getIdentityFlags('<that-identifier>').
  3. Observed: only the features from the last entry are applied. some_feature resolves to its environment default instead of "override-from-first-entry".
  4. Expected: both some_feature and mv_feature resolve to their respective override values and enabled states.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions