Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Flag value is not being fetched on first time #397

Open
mohsinbmwm3 opened this issue Jul 18, 2024 · 4 comments
Open

Feature Flag value is not being fetched on first time #397

mohsinbmwm3 opened this issue Jul 18, 2024 · 4 comments

Comments

@mohsinbmwm3
Copy link

Describe the bug
iOS LD SDK is not able to fetch boolean value on launching app, we have to launch app second time to fetch current value.

To reproduce

  • Launch the ios app and let it fetch FF value.
  • Now kill the app and after killing change the FF value in LD portal.
  • Now launch iOS app and you will see that changed value wont be reflected in the iOS app.
  • Now kill the app again and launch it again, you will see latest value will be reflected here.

One more observation(here we are not killing ios app while changing values in LD portal):

  • Launch the ios app and let it fetch FF value.
  • Now without killing the app change the FF value in LD portal.
  • Now kill the app and relaunch the app and you will see correct value is being reflected in the app.

Expected behavior
When we update value in LD portal, ios SDK should automatically fetch or point to that updated value.

Library version
pod 'LaunchDarkly', '~> 6.0'
XCode and Swift version
Xcode Version 15.2, Swift 5.0

Platform the issue occurs on
iPhone

Additional context
I have configured a bool Feature flag, also made available to mobile. Also same ff is being fetched properly in android, not just in ios somehow it is fetching value in second launch of the app

Code

 - (void) updateUser:(User *)user AndHubInfo:(Hub *)hub {
    LDUser *ldUser = [self buildLDUser:user withHubInfo:hub];
    [self updateLDLibrary:ldUser];
}

 - (BOOL) getFlagValue:(NSString *)featureName defaultValue:(BOOL)value {
    BOOL ffValue = [[LDClient get] boolVariationForKey:featureName defaultValue:NO];    
    return ffValue;
}
 - (LDUser *) buildLDUser:(User *)user withHubInfo:(Hub *)hub {
    LDUser *ldUser = [[LDUser alloc] initWithKey:someRandomId];
    ldUser.email = user.email;
    ldUser.privateAttributes = @[@"email"];
    
    NSMutableDictionary *dict = [self getCustomKeys:hub];
    if (dict != nil) {
        ldUser.custom = dict;
        if ([ldUser.custom objectForKey:kADLDHubID] != nil)
            ldUser.privateAttributes = @[@"email", HubId];
    }
    return ldUser;
}
 - (void) updateLibrary:(LDUser *)ldUser {
    LDConfig *config = [[LDConfig alloc] initWithMobileKey:LaunchDarklyKey];
    [config setStartOnline:YES];
#ifdef DEBUG
    [config setDebugMode:YES];
    [config setDiagnosticOptOut:YES];
#endif
    [config setEvaluationReasons:YES];
    
    [LDClient startWithConfiguration:config user:ldUser completion:^{
    }];
}

@mohsinbmwm3
Copy link
Author

FYI, same behaviour is being observed in sample ios app provided by launch darkly for sdk version 6.0, i updated that sdk with my LD key and required config and same behaviour was observed.

@tanderson-ld
Copy link
Contributor

tanderson-ld commented Jul 18, 2024

Hi @mohsinbmwm3. At the moment, the symptoms you've described don't indicate a bug, but perhaps I'm mistaken.

Do you wait for the completion callback before evaluating flags? If you do not and you make a flag evaluation before the SDK has an opportunity to communicate with the LaunchDarkly services, the SDK will perform the evaluation using cached data from the last time it was connected to the LaunchDarkly services (in most cases this is the last app run).

Options are to wait for the completion (see code below) or to set up a flag listener and make your code reactive.

[LDClient startWithConfiguration:config user:user startWaitSeconds:5.0 completion:^(bool timedOut) {
  if(timedOut) {
      // Client may not have the most recent flags for the configured context
  } else {
      // Client has received flags for the configured context
  }
}];

If I'm mistaken and this is a deeper issue, is this a new behavior? Could it be the case that it wasn't noticed until now?

A reminder that the 6.X version was EOL as of 2023-10-12 and we recommend updating to the latest SDK version.

@tanderson-ld
Copy link
Contributor

@mohsinbmwm3, did my previous comment help clarify or is the issue something else?

@tanderson-ld
Copy link
Contributor

Hi again @mohsinbmwm3 , we haven't heard back for a few weeks and will likely close this issue within the next week due to inactivity. Please let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants