Campaign using custom trigger detects old (cached) campaign's impression

Environment

• Android Studio version: 4.2.2
• Firebase Component: In-App Messaging
• Component version: BOM 28.2.0

Description

When creating a new campaign scheduled with [only] a custom trigger that was also used on a previous campaign, the message does not show – if the previous campaign was already impressed on the device.

From debugging, it seems as though the SDK is looking in the cache for any already-impressed campaign that matches a particular event trigger. In this case, it finds one (that being of a previous campaign), and assumes that the new campaign is therefore also impressed – leading to no display of the new campaign’s message.

Steps to reproduce:

Phase 1: The Setup

1. In the Firebase Console, create a new In-App Messaging campaign (let’s call this Campaign A)
2. In Scheduling, remove the default triggers, and add your own (let’s call this "my_trigger")
3. Publish the campaign
4. In your app, invoke the In-App Message by logging "my_trigger" to Analytics, or In-App Messaging directly
5. Notice it displays just fine, and the impression is logged (and therefore the message will not display on re-trigger, etc.)

At this point, the SDK state is set to reproduce the bug.

Phase 2: The Bug

1. In the Firebase Console, delete Campaign A
2. Create a new campaign (let’s call this Campaign B)
3. In Scheduling, remove the default triggers, and add "my_trigger" again (as we did in Campaign A)
4. Publish the campaign
5. In your app, attempt to invoke the In-App Message by logging "my_trigger" to Analytics, or In-App Messaging directly
6. Observe that the message does not display, and the Logcat output shows I/FIAM.Headless: Already impressed campaign Campaign A ? : true

Conclusions

So my assumption based on this behaviour, together with the info log mentioning the previous (now-deleted) campaign, is that the SDK is not fully aware that the triggering event can be used in multiple campaigns going forward, and assumes it must not show the message. I also assume that it is valid to reuse triggering events for consecutive campaigns, and therefore this is unexpected behaviour.

Note that this behaviour does not occur if the campaign is configured with the on_foreground event. After inspecting the code, my assumption here is that this event is always exempt from inspecting the cache, and therefore avoids the flow leading to the bug.

Relevant Code:

This section is non-applicable in my opinion, as the only “coding” required in the app itself is the line to log the event trigger.

[matthew-niemann]

@aguatno I think you may have labelled this incorrectly. Should it not be inappmessaging?

[google-oss-bot]

Since there haven’t been any recent updates here, I am going to close this issue.

@matthew-niemann if you’re still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.