hotfix/cp-11582-visiolink-push-banner-is-not-being-desplay#355
Conversation
Fix app banners not appearing when a banner-carrying push is tapped from the background
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 6 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 1 file (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Removed comments
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit f29d74e. Configure here.
| } | ||
|
|
||
| if (isChannelIdInvalid(channelId, "loadBanners")) | ||
| return; |
There was a problem hiding this comment.
Invalid channel stalls banner queue
Medium Severity
When processNextBannerRequest dequeues work and loadBanners exits early because the channel ID is still invalid after resolution, nothing invokes processNextBannerRequest again. Remaining entries in pendingBannerRequests are never run and later banner loads can stop processing.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit f29d74e. Configure here.
| } else { | ||
| defaultBannersLoaded = false; | ||
| setLoadingDefaultBanners(false); | ||
| processNextBannerRequest(false); |
There was a problem hiding this comment.
Failed default load never retried
Medium Severity
After a notification banner fetch finishes, the module may auto-start a default banner fetch. If that default request fails, processNextBannerRequest(false) drains the queue but does not schedule another default load, even when defaultBannersLoaded is false. Session default banners can stay unloaded until a full restart of banner initialization.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit f29d74e. Configure here.
| } else { | ||
| if (isLoadingDefaultBanners()) { | ||
| isBannerRequestRunning = false; | ||
| return; |
There was a problem hiding this comment.
Duplicate load drops queued request
Medium Severity
If loadBanners is started from the queue while a default or notification fetch is already marked loading, it clears isBannerRequestRunning and returns without re-queuing the work or calling processNextBannerRequest. That dequeued PendingBannerRequest is discarded.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit f29d74e. Configure here.
2 participants
Fix app banners not appearing when a banner-carrying push is tapped from the background
Note
Medium Risk
Touches core app-banner lifecycle, activity callbacks, and concurrent network loading paths used on every notification open; behavior changes are intentional but broad across the SDK.
Overview
Fixes push-triggered app banners not showing when a notification is opened from the background (CP-11582).
Activity readiness: Adds
isValidHostActivity()soActivityInitializedListenercallbacks run only on a real host activity—not on finishing/destroyed activities or the short-livedNotificationOpenedActivitytrampoline (except when using the notification-opened callback mode).showBannerByIdnow waits on that listener before presenting UI.Banner loading: Replaces a single
loadingflag with separate default vs notification loads, a request queue (PendingBannerRequest), andprocessNextBannerRequest()so concurrent fetches serialize cleanly; after a notification fetch, default banners load automatically if they were skipped. NotificationgetBannerslisteners are tracked separately from default listeners.Resilience: Session init and banner APIs fall back to channel ID from prefs when missing; silent push banners are shown on short sessions and iterated safely.
AppBannerPopupcaps show retries (50 × 100ms) with a safe main looper. Unsubscribe clearsSUBSCRIPTION_PIANO_SEGMENTSfrom prefs.Reviewed by Cursor Bugbot for commit f29d74e. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by cubic
Fixes push app banners not showing when a banner-carrying notification is opened from the background. Addresses CP-11582 by delaying banner UI until a valid host activity is ready and by serializing banner loads with separate default/notification paths.
NotificationOpenedActivityas valid only in callback mode and ignore finishing/destroyed activities.showBannerByIdwaits for activity readiness;AppBannerPopupuses a safe main looper and caps show retries (50x/100ms).SUBSCRIPTION_PIANO_SEGMENTSon unsubscribe.Written for commit f29d74e. Summary will update on new commits.