Giters

Flagsmith / flagsmith-js-client

Javascript Client for Flagsmith. Ship features with confidence using feature flags and remote config. Host yourself or use our hosted version at https://www.flagsmith.com/

Home Page:https://www.flagsmith.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

When `cacheFlags` is on, `identity` is not updated in localStorage cache after being updated in practice

Roeefl opened this issue · comments

commented

Flow description:

  1. Clearing localStorage to start fresh

  2. My user in our web app belongs to an organization with id 281, which results in us generating and passing an identity param to the flagsmith.init() function with 281

  3. Everything works well and in localStorage inside BULLET_TRAIN_DB object, the identity attribute is stored with the latest value: identity: "281___Perception-Point_Test"

  4. Changing my user in our back office to belong to an organization with id 76

  5. Refreshing our web app

  6. The identity variable we generate and pass to flagsmith.init() is correct and contains the organization id 76.
    Nevertheless, this is overridden by the one stored in localStorage cache, which is NOT UPDATED after the change, and stays as it was in 3 (contains identity: "281___Perception-Point_Test")

The Request URL to flagsmith looks like this:

Request URL: https://api.flagsmith.com/api/v1/identities/?identifier=281___Perception-Point_Test

Why is the localStorage cache not updated ? and why is the identity overridden by the one from the cache, even though we generate it properly and pass it to flagsmith.init() explicitly ?

This has actually apparently become a severe issue for us which we did not realize (until yesterday) what was causing.

Would appreciate you guys taking a look or explaining / pointing us to what we might be missing or doing wrong.

Thanks!
Roee
Percpetion Point

gz#197

commented

I see, yes I think you're correct. It's quite a specific use case but it sounds like if a different identity was provided prior to async storage retrieval then the stored data should be totally ignored. I'll adjust and test this case now and provide an update on findings.

commented

This has been resolved in flagsmith,flagsmith-es and react-native-flagsmith version 3.14.2. With enableLogs set to true this use-case is also now logged.

image

commented

Please let me know if the version resolves the issue for you, and feel free to reopen if you believe there is still an issue!

commented

@kyle-ssg That sounds awesome. Thank you for the quick response and sorry that it took me well over a month to reply, I actually missed your answers . 💟

I'm upgrading our flagsmith package to the latest version now and checking if this issue has been resolved for us.

Much obliged good Ser.

commented

@kyle-ssg FYI this was a huge leak when we think about it :p
I'm glad we could help out in resolving it before it became a critical issue for some big client