Skip to content

Fix: NotificationOpenedActivity "freeze" when a large amount of notification is clicked #2304

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

Merged
merged 3 commits into from
May 22, 2025

Conversation

jinliu9508
Copy link
Contributor

@jinliu9508 jinliu9508 commented May 20, 2025

Description

One Line Summary

Move the backend call updateNotificationsAsOpened to a background thread to prevent blocking the next activity from opening when many notifications are clicked.

Details

Motivation

Fix a frozen screen issue that occurs when a large number of notifications are clicked simultaneously.

Scope

  • The updateNotificationsAsOpened operation is now performed silently in the background. This means we no longer wait for its response before opening the destination activity upon a notification click. As a result, the order of this operation relative to other operations is no longer guaranteed. A potential risk is that IDs may change before updateNotificationsAsOpened completes on the backend. However, since all data is finalized at the time the requests are created, data integrity is maintained without blocking the UI.
  • OSPrimaryCoroutineScope is also used by other backend operations like createUser and updateSubscription. As a result, these operations could potentially be delayed if too many updateNotificationsAsOpened calls are made.
    One possible improvement would be to introduce a SecondaryCoroutineScope to handle lower-priority updates, but since they’re all backend calls, the overall time required to complete them remains roughly the same.
  • ⚠️ Important: If the app is force-closed shortly after a notification click, some updateNotificationsAsOpened calls may be interrupted, and those clicks might not be updated on the backend.

Testing

Unit testing

A new unit test ensures that openDestinationActivity is not blocked when clicking on a large number of notifications.

Manual testing

Tested on a Pixel 9 (API 35) emulator. Clicking a summary notification that groups 50+ individual notifications opens the app seamlessly. The updateNotificationsAsOpened calls are successfully processed in the background after the app is opened.

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

@jinliu9508 jinliu9508 added the WIP Work In Progress label May 20, 2025
@jinliu9508 jinliu9508 requested review from jkasten2 and nan-li May 22, 2025 17:08
@jinliu9508 jinliu9508 removed the WIP Work In Progress label May 22, 2025
@jinliu9508 jinliu9508 force-pushed the screen-frozon-click-numerous-notifications branch from ffb4b6d to 861929f Compare May 22, 2025 17:35
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.

Do we need suspend on notificationOpened any more since we moved the network call to OSPrimaryCoroutineScope?

@jinliu9508
Copy link
Contributor Author

Do we need suspend on notificationOpened any more since we moved the network call to OSPrimaryCoroutineScope?

Good question! I think we still need it because openDestinationActivity is suspending function that is also called in notificationOpened() and it is used on two different places. So refactoring this will be out of the scope of this PR. I also checked updateNotificationAsOpened and it looks like it is still suspending. We just need to make it suspend in a background thread so its run time doesn't scale up in the main thread.

@jinliu9508 jinliu9508 force-pushed the screen-frozon-click-numerous-notifications branch from 861929f to 817a9cf Compare May 22, 2025 18:06
@jinliu9508 jinliu9508 merged commit 3a6e913 into main May 22, 2025
2 checks passed
@jinliu9508 jinliu9508 deleted the screen-frozon-click-numerous-notifications branch May 22, 2025 19:01
@jinliu9508 jinliu9508 mentioned this pull request May 22, 2025
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.

2 participants