Skip to content

Conversation

@abdulraqeeb33
Copy link
Contributor

@abdulraqeeb33 abdulraqeeb33 commented Nov 12, 2025

Description

One Line Summary

Handling race condition during initWithContext

Details

Motivation

#2192 (comment)
To address this issue

Scope

Internal racecondition handling.

Testing

Unit testing

NA

Manual testing

Smoke tested the app

Affected code checklist

  • Notifications
    • Display
    • Open
    • Push Processing
    • Confirm Deliveries
  • Outcomes
  • Sessions
  • In-App Messaging
  • REST API requests
  • Public API changes

Checklist

Overview

  • I have filled out all REQUIRED sections above
  • PR does one thing
    • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
  • Any Public API changes are explained in the PR details and conform to existing APIs

Testing

  • I have included test coverage for these changes, or explained why they are not needed
  • All automated tests pass, or I explained why that is not possible
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
    • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
  • I have reviewed this PR myself, ensuring it meets each checklist item
    • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

This change is Reviewable

Comment on lines 332 to 342
// Check state and provide appropriate error messages
when (initState) {
InitState.FAILED -> {
throw IllegalStateException("Initialization failed. Cannot proceed.")
}
InitState.NOT_STARTED -> {
throw IllegalStateException("Must call 'initWithContext' before 'logout'")
}
InitState.IN_PROGRESS, InitState.SUCCESS -> {
// Continue - these states allow proceeding (will wait if needed)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicate code, can we make a function for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good callout, i centralized all of this. including the code path for suspend and blocking.

trigger.complete()

// Wait for initialization to complete (internalInit runs asynchronously)
var attempts = 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the wait mechanism for the initialization seems repetitive in the test. Can we clean this up?

Copy link
Member

@jkasten2 jkasten2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather not have waitUntilInitInternal return, but initState == InitState.IN_PROGRESS. It creates an extra inconsistent state and doesn't provide any benefit I can see.

I would rather we just wait here as long as it takes so code doesn't have to consider both states. PR #2412 does this, and only logs if it is taking longer than expected.

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

Successfully merging this pull request may close these issues.

4 participants