BUG : Race condition when initializing SDK in EventRepository #492
Comments
|
Thanks for opening this issue! We'll get back to you shortly. If it is a bug, please make sure to add steps to reproduce the issue. |
|
Hey @ZacBeemer-JaneApp, Thanks for raising this issue. It seems you're using the self-hosted control plane URL and the metrics config is missing. I would request you to add the following config: Or, try using the default control plane and try again: Let us know if you are still facing any issues after performing the above steps. |
|
@1abhishekpandey Thank you for the suggestion! We'll look at implementing it and get back to you with whether it made a difference or not. Do you believe it's worth enhancing the logic to be more resilient / communicative regarding this issue in case other groups run into it as well? |
|
Sure, we will definitely work on improving that in the future. Currently, we are developing a new Android SDK built from scratch in Kotlin, which will address many improvements, including the issue you mentioned. |
Describe the bug
There appears to be a race condition causing silent failures when the
EventRepositoryobject is first initialized. This prevents the app from sending events to Rudderstack.We are working on a React Native project using the Rudderstack React Native SDK. We noticed that we were not receiving any messages from Android devices and, through a long and tedious process, uncovered that this Android SDK has an uncaught race condition which is silently causing the SDK Initialization process to hang and never complete.
The issue stems from how the RudderServerConfigManager class is using
ReentrantLock.brokenThread()logic beforenormalThread()then the call tolock.unlock()is never performed andnormalThread()cannot proceed as it can never obtain the lock.More specifically, the scenario being played out in our testing is as follows:
EventRepositoryis createdRudderServerConfigManagerconstructor calls on RudderServerConfigManager.fetchConfig() which submits a task to be performed asynchronouslyfetchConfig()method is exited regardless of whether or not the async logic is performedEventRepositoryconstructor then eventually calls EventRepository.initiateSDK()Server ConfigexistsRudderServerConfigManager.fetchConfig()having been completed, which is not guaranteedRudderServerConfigManager.fetchConfig()has not completed yet (ie. Slow download, device thread prioritization), theninitiateSDK()will continue and enter its retry-loopinitiateSDK()spawned a new Thread, it returns almost immediately andEventRepositoryworks its way down to EventRepository.initiateRudderReporterFromPrefetchedConfig()RudderServerConfigManager.fetchConfig()having completedData Plane URLData Plane URLis not available,ReportManager.enableStatsCollection()throws an uncaught NullPointerExceptionReentrantLockinRudderServerConfigManageris not using the following suggested structure, the Thread that previously claimed the lock will never release it and all other Threads waiting for it will be stuck.flush()will throw an error (if log output is explicitly configured), but otherwise not kill the appTo Reproduce
Steps to reproduce the behaviour:
Expected Behavior
The event should be fired off and no errors should be observed
Screenshots
Version of the Android SDK
Version of the Rudderstack Android SDK
Mobile device mode integration
SDK initialisation snippet
Check for Correct Usage of writeKey and dataPlaneUrl
Confirm that the correct
writeKeyanddataPlaneUrlare utilized during SDK initialization.dataPlaneUrlfrom being correctly initializedThe text was updated successfully, but these errors were encountered: