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] Call initWithContext on all entry points #2018

Merged
merged 1 commit into from
Mar 12, 2024

Conversation

jkasten2
Copy link
Member

@jkasten2 jkasten2 commented Mar 6, 2024

Description

One Line Summary

Call initWithContext on all entry points where the app process can start, fixing the inconsistencies in initialization which addresses some rare edge cases.

Details

We call OneSignal.initWithContext on most entry points but some were missed. Consistency is important as differences can lead to edge case bugs that are hard to reproduce and debug.

One recent example of this was with ReceiveReceiptWorker, its inconsistency lead to a hard to debug issue that was uncovered by PR #2012

In this PR an issue was discovered in NotificationGenerationWorker. It almost always runs after receiving a push, but not guaranteed. It was checking for OneSignal.isInitialized but instead should always call initWithContext as it can be an entry point to the app process.

The ADMMessageHandlerJob may or may not have had an issue, but we matched up the initWithContext behavior to be safe.

Related issues

Should fix #1282

Motivation

Initialization consistency is important as differences can lead to edge case bugs that are hard to reproduce and debug.

Scope

Only effects initialization on internal entry points for OneSignal events.

Testing

Unit testing

No unit test coverage exists on these entry points, to test such code these would have to be abstracted out which is out of scope of this PR.

Manual testing

Ensure notifications are displayed on an Android 6 emulator, both when the app process is in the background when it it was stopped.

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
  • 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.
  • I have reviewed this PR myself, ensuring it meets each checklist item

This change is Reviewable

We call OneSignal.initWithContext on most entry points but some were
missed. Consistency is important as differences can lead to edge case
bugs that are hard to reproduce and debug.

One recent example of this was with ReceiveReceiptWorker, its
inconsistency lead to a hard to debug issue that was uncovered by
commit 893381b.

In this commit an issue was discovered in NotificationGenerationWorker.
It almost always runs after receiving a push, but not guaranteed. It
was checking for OneSignal.isInitialized but instead should always call
initWithContext as it can be an entry point to the app process.

The ADMMessageHandlerJob may or may not have had an issue, but we
matched up the initWithContext behavior to be safe.
@jkasten2 jkasten2 requested review from nan-li and emawby March 6, 2024 21:53
Base automatically changed from feat/add_backoff_to_operation_retries to main March 7, 2024 18:41
@jkasten2 jkasten2 merged commit 3c79306 into main Mar 12, 2024
2 of 3 checks passed
@jkasten2 jkasten2 deleted the fix/always-initWithContext-on-process-entry-points branch March 12, 2024 17:40
@jkasten2 jkasten2 mentioned this pull request Mar 29, 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
2 participants