[discourse] Adding new records to the segment after adding to the flag

[markphelps]

Originally posted by member on Discourse

Hello Team!

I’ve encountered one feature of the segments, and I can’t figure out yet whether this behavior is normal or not.

Once the segment has been created and added for use by the flag, everything

is ok, but when I make changes to the segment already used, they only work after I delete and add the same segment for the flag again. At the same time, enabling and disabling Default Rollout is applied immediately (True/False).

Should a segment update work on the fly, or is it only updated when Rollouts are added? (I’m using the client-side SDK)

[dosubot[bot]]

This is expected behavior with the Flipt client-side SDK. Segment updates (like adding new records) only take effect after the client refreshes its full snapshot from the backend. The SDK bundles all flag, rule, rollout, and segment data into a single snapshot, and there’s no support for segment-specific or incremental updates—everything is updated together when the snapshot is refreshed. That’s why changes to a segment aren’t reflected until you trigger a refresh (or re-add the segment, which also causes a refresh). Default Rollout toggles apply immediately because they update the snapshot as well. To see segment changes take effect, call the client’s refresh() method or re-initialize the client to fetch the latest snapshot from the backend.
Reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[markphelps]

Reply from mark on Discourse:

member:

Should a segment update work on the fly, or is it only updated when Rollouts are added? (I’m using the client-side SDK)

Hi there. Sorry you are running into issues with stale segments in evaluation.

Updating segments should work on the fly, or at least will on the next poll from the client SDK.

Are you able to give more examples like what you are updating in the segment? And/or can you share an export of your flags/segments so that we can help debug?

[markphelps]

Reply from member on Discourse:

Hi @mark ! Thanks for the quick response. After several tests, I figured out what the problem was, namely the cache.

    cache:
      backend: memory
      enabled: false

This works well (segments are updated instantly)

I tried using Redis instead of Memory but that didn’t solve the problem.

[markphelps]

Reply from member on Discourse:

Now I’m trying to set up a cache (Redis) and it works weird (same behavior with memory).

    cache:
      backend: redis
      enabled: true
      redis:
        host: localhost
      ttl: 60s

If I set the value ttl: 60s

I expect that after editing a segment my changes will be applied immediately or after 60 seconds after clearing cache, but it doesn’t happen after 60 or 5 minutes. The client still uses old values ​​until browser cache is reset.

If I set the value ttl: 10s it works 50/50.

There is nothing suspicious in the Flipt logs, entries in Redis are created and deleted in a timely manner.

Maybe I’m doing something wrong?

p.s I use @flipt-io/flipt-client-react - npm

[markphelps]

Reply from mark on Discourse:

So one thing to note is cache isn’t really necessary for Client Side SDKs as the state that is served to the clients is already loaded in memory on the server.

Cache is really only relevant if you are doing evaluation on the Flipt Server for each request, like if you are using one of our Server SDKs.

So the caching configuration part of this might be a red herring as I don’t think its contributing to the issue of stale data in the React SDK.

Are you using the latest version of the React SDK? or at least v0.1.0 ? There was quite a bit of rework in 0.1.0 that should make the state more… reactive and prevent the need from having to reload the browser to get state changes.

[markphelps]

Reply from member on Discourse:

Yes, I’m using version 0.1.0 (I saw that version 0.2.0 was recently released) and everything works fine with the Flipt cache disabled. I was just wondering why this behavior with cache enabled. Thank you for the explanation!