Feature value shows [object Object] after saving segment overrides

[talissoncosta]

How are you running Flagsmith

SaaS at flagsmith.com

Describe the bug

After saving segment overrides on a feature flag in an environment with v2 feature versioning enabled, the feature value displays [object Object] instead of the actual value. This affects both:

• The feature list on the features page
• The Control Value field inside the Edit Feature modal

Refreshing the page resolves the issue temporarily, as it re-fetches from the list endpoint which returns primitive values.

Root cause: In feature-list-store.ts, the v2 segment override save path (editVersionedFeatureState, ~line 757-769) fetches the updated feature state via getVersionFeatureState, which returns feature_state_value as a FeatureStateValue object ({ boolean_value, string_value, type, ... }). This object is spread directly into keyedEnvironmentFeatures without converting it to a primitive using Utils.featureStateToValue().

The v2 value save path (line 820) correctly converts it:

feature_state_value: Utils.featureStateToValue(featureState.feature_state_value)

But the v2 segment save path (line 766-769) does not:

store.model.keyedEnvironmentFeatures[projectFlag.id] = {
  ...store.model.keyedEnvironmentFeatures[projectFlag.id],
  ...environmentFeatureState, // ← object feature_state_value not converted
}

Steps To Reproduce

1. Go to a project with v2 feature versioning enabled
2. Navigate to the features list
3. Open a feature flag that has a value set
4. Go to the Segment Overrides tab
5. Make any change (add, edit, or remove a segment override)
6. Save the changes
7. Re-open the feature and save segment overrides a second time
8. Observe [object Object] displayed as the feature value in the list and in the Control Value field

Note: The issue only appears on the second save. On the first save, keyedEnvironmentFeatures still holds the original primitive value from the initial list fetch. The v2 segment path overwrites it with the object form of feature_state_value. On the second save, the store already contains the corrupted object value, which then renders as [object Object].

Expected behavior

The feature value should display the correct primitive value (string, number, or boolean) after saving segment overrides, without requiring a page refresh.

Screenshots

https://www.loom.com/share/73ba9ff0e93a464191a3699558b139c6

Suggested fix

In feature-list-store.ts around line 766, convert feature_state_value before storing:

const environmentFeatureState = res.data.find((v) => !v.feature_segment)
if (store.model?.keyedEnvironmentFeatures && environmentFeatureState) {
  store.model.keyedEnvironmentFeatures[projectFlag.id] = {
    ...store.model.keyedEnvironmentFeatures[projectFlag.id],
    ...environmentFeatureState,
    feature_state_value: Utils.featureStateToValue(
      environmentFeatureState.feature_state_value,
    ),
  }
}

[FocusMode-coder]

Hey! I may be able to help with this bug.

I build custom fixes for Python projects and automation systems.

If you'd like help resolving this issue quickly feel free to reach out.

Happy to take a look 👍

[talissoncosta]

Related: Segment override save crashes with Cannot read properties of undefined (reading 'uuid')

This is a downstream consequence of the same root cause. After the store gets corrupted with the object feature_state_value:

1. User saves segment overrides again
2. The corrupted object gets passed through convertSegmentOverrideToFeatureState → createFeatureVersion
3. The API rejects the malformed data
4. versionRes.data comes back undefined
5. useFeatureVersion.ts:203 crashes: versionRes.data.uuid → Cannot read properties of undefined (reading 'uuid')

This was observed in a customer video at ~1:20 timestamp (Slack thread CTF0THS2D/p1773326639982579).

Additional fix: useFeatureVersion.ts:203 should guard against versionRes.data being undefined before accessing .uuid, to surface the actual API error instead of crashing.

Fixing the root cause (converting feature_state_value with Utils.featureStateToValue()) should prevent this from happening, but the guard is still good defensive coding.