fix: in-app messages not displaying when app returns from background with SSE enabled #663
Conversation
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request. |
| private fun onActivityResumed() { | ||
| logger.debug("GistSdk Activity resumed") | ||
| fetchInAppMessages(state.pollInterval) | ||
| fetchInAppMessages(state.pollInterval, forceFetch = true) |
There was a problem hiding this comment.
Won't this be called from all activities not just background -> foreground transition? If you test this with settings activity or inline activity, you will see polling forced multiple times
|
|
Build available to test |
|
📏 SDK Binary Size Comparison Report
|
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #663 +/- ##
============================================
- Coverage 69.07% 69.02% -0.05%
Complexity 838 838
============================================
Files 149 149
Lines 4601 4604 +3
Branches 628 628
============================================
Hits 3178 3178
Misses 1189 1189
- Partials 234 237 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| private val processLifecycleOwner = mockk<LifecycleOwner>(relaxed = true) | ||
| private val lifecycle = mockk<Lifecycle>(relaxed = true) | ||
| private val mainThreadPoster = mockk<MainThreadPoster>(relaxed = true) | ||
| private val gistQueue = mockk<GistQueue>(relaxed = true) |
There was a problem hiding this comment.
Should we actually add a test to verify the new behavior?
|
|
## [4.16.1](4.16.0...4.16.1) (2026-02-24) ### Bug Fixes * in-app messages not displaying when app returns from background with SSE enabled ([#663](#663)) ([9fb8156](9fb8156))
3 participants
Reproducible
Root Cause
When SSE support was introduced (#636, merged Jan 13), a guard was added to
fetchInAppMessages()that skips the HTTP fetch entirely when SSE is active (shouldUseSse = true). This was correct for skipping recurring polling, but italso removed the one-time catch-up fetch that previously ran on every
onActivityResumed().The sequence of events:
onActivityResumed()callsfetchInAppMessages()fetchInAppMessages()sees SSE is active → returns immediately without fetchingOn a cold start this doesn't happen because SSE hasn't been enabled yet (the flag comes from server response headers), so the first HTTP fetch runs before SSE is activated.
Fix
Added a
forceFetchparameter tofetchInAppMessages(). When the app resumes from background,onActivityResumed()passesforceFetch = true, which performs a one-time HTTP fetch even when SSE is active — catching up on any messages missed while the SSE connection was disconnected. All other callers default toforceFetch = falseand behave exactly as before.Note
Medium Risk
Changes foreground lifecycle behavior to add an extra network fetch, which could impact message duplication/timing and API load if triggered unexpectedly; scope is limited to SSE-enabled, identified-user paths and is covered by unit tests.
Overview
Fixes missed in-app messages when returning from background with SSE enabled by performing a one-time
gistQueue.fetchUserMessages()before starting the SSE connection on app foreground.Updates DI to inject
GistQueueintoSseLifecycleManager, and expandsSseLifecycleManagerTestwith new coverage ensuring the catch-up fetch runs only for identified users using SSE (and not for polling/anonymous flows), including background→foreground scenarios.Written by Cursor Bugbot for commit 7171ac3. This will update automatically on new commits. Configure here.