[MOB-9340] Fix for removing recalled campaigns from device memory#893
Open
sumeruchat wants to merge 11 commits intomasterfrom
Open
[MOB-9340] Fix for removing recalled campaigns from device memory#893sumeruchat wants to merge 11 commits intomasterfrom
sumeruchat wants to merge 11 commits intomasterfrom
Conversation
…val- Ensure in-app messages are marked as consumed before being removed from local storage to prevent re-display.- Add unit test to verify that recalled messages are correctly marked as consumed and inAppConsume is called.
…ter message removal in `IterableFirebaseMessagingService`.- Mark messages as consumed before removal in `IterableInAppManager` to prevent re-display.
…Central, upgrade Kotlin to 1.9.22, and configure JVMtoolchain to 17. Refactor javadoc task for compatibility with new Android Gradle Plugin.
…or message retrieval- Replaced array with Arrays.asList for better readability and flexibility.- Added missing import for Arrays.
…n-app messages are marked as consumed through the API before being removed from storage to prevent re-display.
Ayyanchira
reviewed
Apr 4, 2025
Comment on lines
+24
to
+27
| buildFeatures { | ||
| buildConfig true | ||
| } | ||
|
|
Member
There was a problem hiding this comment.
Lets remove all the build and embedded related changes from this PR
| // Mark message as consumed before removing it to prevent it from being displayed | ||
| localMessage.setConsumed(true); | ||
| storage.removeMessage(localMessage); | ||
| api.inAppConsume(localMessage, null, null, null, null); |
Member
There was a problem hiding this comment.
Lets get a confirmation from product to see if recalled message should be consumed. As it could affect the analytics.
Also referencing localMessage after its removal could cause problems.
Ayyanchira
reviewed
Jan 8, 2026
Comment on lines
+324
to
+325
| // Mark message as consumed before removing it to prevent it from being displayed | ||
| message.setConsumed(true); |
Member
|
This PR can be closed. Silent push not received to SDK yet |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket: https://iterable.atlassian.net/browse/MOB-9340
ISSUE: In-App Messages Remain Visible After Server Recall
PROBLEM DESCRIPTION:
In-app messages continue to display on Android devices even after they've been recalled server-side. The SDK recognizes the recall event but fails to mark these messages as consumed locally, causing them to remain visible to users.
ROOT CAUSE:
During synchronization, the SDK correctly identifies messages that have been removed from the server (missing from server response but present in local storage)
FIX IMPLEMENTED:
Modified the syncWithRemoteQueue() method in IterableInAppManager.java to mark messages as consumed before removing them from storage when they're no longer present in the server response.
The changes are minimal and targeted, similar to the iOS fix. Added unit test to verify the fix works correctly.