Skip to content

Conversation

@nan-li
Copy link
Contributor

@nan-li nan-li commented Jan 23, 2026

Description

One Line Summary

Display IAMs with triggers added before first fetch on cold start.

Details

On subsequent cold starts, if triggers were added very early in the app lifecycle (before the first IAM fetch completed), in-app messages matching those triggers would not display even though they should have been eligible for redisplay.

Motivation

Product request

Scope

This only affects cold starts (process restarts) and does not impact warm starts from backgrounding, where existing redisplay behavior is preserved.

Testing

Unit testing

Need to add

Manual testing

Tested on API 35 emulator.
Add trigger immediately after initialization, and confirm the IAM now displays after the changes in this PR.
Tested with pausing and unpausing.

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

- Addresses issue where in-app messages wouldn't display on cold starts if their triggers were added very early (before IAM fetch completed).
- Tracks triggers added before first fetch completes
@github-actions
Copy link
Contributor

📊 Diff Coverage Report

Diff Coverage Report

Threshold: 80%

Changed Files Coverage

  • InAppMessagesManager.kt: 388/476 lines (81.5%)

Overall Coverage

388/476 lines covered (81.5%)

📥 View workflow run

private var hasCompletedFirstFetch: Boolean = false

// Tracks trigger keys added early on cold start (before first fetch completes), for redisplay logic
private val earlySessionTriggers: MutableSet<String> = mutableSetOf()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we make it concurrent? are we envisioning this to be cleared/added/updated at the same time?

this.messages = newMessages as MutableList<InAppMessage>

// Apply isTriggerChanged for messages that match triggers added too early on cold start
if (earlySessionTriggers.isNotEmpty()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to write a against this?

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.

3 participants