jerielng
commented
8 months ago Hi @markanderson-underdog, thanks for raising this. If I understand correctly, you are receiving the 100%-on value at your first launch of the app, and then while the app is still opened, turning it to 0% remotely before quitting and re-opening? Are you re-syncing your feature flags before killing the app?
I believe that should be expected behavior, unless I've misrepresented the above scenario? Feature flag values are only refreshed whenever that /feature_flags/sync API call is made. If no refresh call is made between steps 4 and 5, the Braze SDK will be re-initialized upon launch with whatever cached values there were from the previous sync. When the SDK is initialized, it kicks off a refresh call as soon as it can, but until that refresh call returns, it has no knowledge of the server's last state.
lowip
Platform
iOS
Platform Version
iOS 17.2
Braze SDK Version
7.5.0
Xcode Version
15.2
Computer Processor
Apple (M1)
Repro Rate
80% of the time
Steps To Reproduce
Expected Behavior
After step 5, new Feature Flag value (off) is respected and given to the application on init-ing Braze
Actual Incorrect Behavior
I can see in a Network Proxy tool that the Braze SDK is indeed fetching the new FF and it is received as off from the API, often (~80%) the Braze SDK inits before the API response comes in to update the FF value, and as a result the incorrect value of ON is given to the app on init.
See attached images, taken around step 5 of the STR: First image - Braze is initialized, and we check the feature flags (shows the flag is ON, even though the flag is set to OFF on the backend)
Second image - about ~350 ms later, the braze request to sync the flags returns, and shows no flags (which is correct)
Third image - almost 1 second later, if we re-query the flags, we're finally shown correct state
Verbose Logs
No response
Additional Information
No response