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

[Fix] RecoverFromDroppedLoginBug not running in very rare cases #2084

Conversation

jkasten2
Copy link
Member

@jkasten2 jkasten2 commented May 9, 2024

Description

One Line Summary

Fix a very rare case where RecoverFromDroppedLoginBug may not run.

Details

Motivation

We want to ensure RecoverFromDroppedLoginBug always runs, otherwise we can't recover some end-users who would be stuck in a bad state, where the OperationRepo queue stalls. While the case where this would happen would be extremely rare, the orignal code had a landmine, where if initialization code was refactored the rare case could be become much more common. The existing Unit Test did not cover out of order initialization either.

Scope

Only affects RecoverFromDroppedLoginBug.kt

Testing

Unit testing

  • New failing test to prove issue
  • Test is passing and was also refactored in the same commit as the interface changed.

Manual testing

On a Android 6 emulator ensured RecoverFromDroppedLoginBug.isInBadState() runs.

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

Add test to prove onOperationRepoLoaded doesn't always fire.
Refactored test to make it easier to share mocks between tests.
This change fixes a rare bug where RecoverFromDroppedLoginBug may not
run. While very rare this could happen if start was called on
OperationRepo first and it finished before
RecoverFromDroppedLoginBug.start was called.

We swapped out EventProducer for a CompletableDeferred to address this
issue. CompletableDeferred is a better fit as we simply need to wait
until something is initialized, and it will never fire more than once.

We also refactored RecoverFromDroppedLoginBugTests to account for the
change, but improved the testing to ensure the operation itself is
correct.
@jkasten2
Copy link
Member Author

jkasten2 commented May 10, 2024

Flaky unrelated test: Fixed this in PR #2083

com.onesignal.core.internal.http.HttpClientTests > ensure next request is delayed by the Retry-After value FAILED
    java.lang.AssertionError: Expected null but actual was com.onesignal.core.internal.http.HttpResponse@6e229864
        at com.onesignal.core.internal.http.HttpClientTests$1$11.invokeSuspend(HttpClientTests.kt:252)
        Caused by:
        java.lang.AssertionError: Expected null but actual was com.onesignal.core.internal.http.HttpResponse@6e229864
            at com.onesignal.core.internal.http.HttpClientTests$1$11.invokeSuspend(HttpClientTests.kt:252)

@jkasten2 jkasten2 changed the title WIP [Fix] RecoverFromDroppedLoginBug not running in very rare cases [Fix] RecoverFromDroppedLoginBug not running in very rare cases May 10, 2024
Copy link
Contributor

@jinliu9508 jinliu9508 left a comment

Choose a reason for hiding this comment

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

LGTM!

While we have discussed moving the initialization process to the constructor as a potential solution for now, this approach is more precise and can prevent potential breakdowns resulting from future refactors.

@jkasten2 jkasten2 mentioned this pull request May 10, 2024
18 tasks
Base automatically changed from tests/fix-flaky-tests-2024-05-09 to main May 10, 2024 20:37
@jkasten2 jkasten2 merged commit 50e4c46 into main May 10, 2024
2 checks passed
@jkasten2 jkasten2 deleted the fix/RecoverFromDroppedLoginBugTests-not-running-in-very-rare-cases branch May 10, 2024 20:38
@jinliu9508 jinliu9508 mentioned this pull request May 16, 2024
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.

None yet

2 participants