Skip to content

Make NotificationResultProcessor.emit wait until the batch is processed - #7640

Open
Johennes wants to merge 1 commit into
element-hq:developfrom
Johennes:johannes/processor-lifecycle
Open

Make NotificationResultProcessor.emit wait until the batch is processed#7640
Johennes wants to merge 1 commit into
element-hq:developfrom
Johennes:johannes/processor-lifecycle

Conversation

@Johennes

@Johennes Johennes commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Content

This change makes NotificationResultProcessor own its lifecycle instead of relying on the push handler having been constructed first. emit starts the collector if it is not running, and results go through an unlimited channel, which holds items until a receiver takes them, so nothing is lost while the collector is starting or between it being launched and actually subscribing. emit also suspends until its batch has been processed, so the worker only completes once the notification or ringing call has been set up, and the wakelock or foreground service the worker holds covers the whole path rather than ending while the batch is still queued. Finally, a batch that throws while being processed is logged instead of cancelling the collector, which previously stopped all further notifications for the life of the process.

Motivation and context

NotificationResultProcessor currently hands resolved push events from the fetch worker to a collector running on the app scope. That collector is only started from DefaultPushHandler, which is only created when a push receiver runs in the current process, and the shared flow in between has no replay, so values emitted while nobody is subscribed are dropped. A FetchPendingNotificationsWorker that WorkManager runs in a fresh process, for example a retry after the process was killed or an expedited job that was deferred, therefore fetches and decrypts the events and then emits them into nothing. No notification is shown and nothing is logged.

Screenshots / GIFs

None.

Tests

See unit tests.

Tested devices

None.

Checklist

  • I am aware of the etiquette.
  • This PR was made with the help of AI:
    • Yes. In this case, please request a review by Copilot.
    • No.
  • Changes have been tested on an Android device or Android emulator with API 24
  • UI change has been tested on both light and dark themes
  • Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
  • Pull request is based on the develop branch
  • Pull request title will be used in the release note, it clearly defines what will change for the user
  • Pull request includes screenshots or videos if containing UI changes
  • You've made a self review of your PR

Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
@github-actions

github-actions Bot commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

  • If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
  • Your branch should be based on origin/develop, at least when it was created.
  • The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
  • The test pass locally running ./gradlew test.
  • The code quality check suite pass locally running ./gradlew runQualityChecks.
  • If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

@codecov

codecov Bot commented Sep 3, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 94.44444% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.97%. Comparing base (67f287a) to head (14254b2).

Files with missing lines Patch % Lines
.../impl/notifications/NotificationResultProcessor.kt 94.44% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #7640      +/-   ##
===========================================
- Coverage    80.99%   80.97%   -0.02%     
===========================================
  Files         2781     2781              
  Lines        81847    81859      +12     
  Branches     11257    11258       +1     
===========================================
- Hits         66291    66288       -3     
- Misses       11211    11228      +17     
+ Partials      4345     4343       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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.

1 participant