-
Notifications
You must be signed in to change notification settings - Fork 230
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
[SDK-2473] Fix for early branch init on install #1451
base: master
Are you sure you want to change the base?
Conversation
|
||
BranchEvent *earlyEvent = [BranchEvent standardEvent:BNCAddToCartEvent]; | ||
NSLog(@"Logging Early Event: %@", earlyEvent); | ||
[earlyEvent logEvent]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this supposed to queue an event before the sdk is initialized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah
if (!Branch.trackingDisabled) { | ||
if (![req isKindOfClass:[BranchInstallRequest class]] && !self.preferenceHelper.randomizedBundleToken) { | ||
[[BranchLogger shared] logError:@"User session has not been initialized!" error:nil]; | ||
self.networkCount = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be a thread safe operation? Can other areas be checking this value at the same time, and executing/not executing an event because of it? cc @NidhiDixit09
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gdeluna-branch networkCount
is defined as a property and its protected using @synchronized (self)
inside its accessor functions. So its thread safe.
@nsingh-branch I think we should add this fix for opens also. Its a rare case to happen but technically else if
condition has the same issue.
Summary
When a BranchEvent is logged on first open before the SDK is initialized, we try to initialize first to log it properly. However, the SDK was reaching a state where
processNextQueueItem
was stuck and unable to process the first install or the event and nothing would happen until the next session. It seems like this was due to the BranchEvent request basically causing the queue to get stuck and the SDK to stay in an initializing state sinceprocessNextQueueItem
would be skippednetworkCount
wasn't equal to 0.This change updates the if statement to also set the networkCount to 0 which allows the install to be processed and then the event to be processed after that. Since this statement only applies to non-install or open events on the first session, this change shouldn't have an effect on other cases.
Motivation
Fix for a bug, mainly for the Adobe Branch plugin, but other clients may be trying to log events early in some cases as well.
Type Of Change
Testing Instructions
Try out the updated testbed which logs an event from the AppDelegate before the SDK is initialized.
cc @BranchMetrics/saas-sdk-devs for visibility.