BUG - sev-3 - All - Messaging push notification deeplinking persists through logout

[TKDickson]

What happened?

Messaging push notifications right now - for lack of a better term - are too 'sticky'. (see video towards end of ticket, or read through steps here)

• I sent a messaging push, and used it to deeplink into the app on a few different devices.
• Then on one of those devices I was logged out (not manually, but had been kicked out), and when I logged back in manually as that user again, it deeplinked me to that same message.
• So on another device, I logged out manually and logged back in as a DIFFERENT user, and it also tried to deeplink me in to that same message - but displayed an error page, since that user didn't have access to the message (from the original push).

Have confirmed that this is also happening on the 2.36 RC branch, so it's not specific to the RQ update I'm testing.

Also, I've written this with messaging information because I don't have the ability to send any other kind of notification in staging. I assume currently this would happen with all notifications, not just messaging, but I can't test that assumption.

Specs:

• Device:
• OS:
• User Account: +226 is a user with messaging (therefore PN) access
• Accessibility State:

Steps to Reproduce

• Log into a device as user 1. Send a push notification to user 1, and use it to deeplink into that activity (we'll call it message 1, since that's the only one I can control in staging)
• Log out of the device, and back in as user 2. After the login sequence, are deeplinked into messaging and attempt to pull up message 1, but get an error message.

Desired behavior

I don't know what the heck is going on technically, but the user behavior here is that deeplinking from a specific push notification should happen once (when you tap on a push notification the first time), and then never again.

Acceptance Criteria

Bug Severity - BE SURE TO ADD THE SEVERITY LABEL

See [Bug Tracking](https://department-of-veterans-affairs.github.io/va-mobile-app/docs/QA#issue-severity) for details on severity levels

• Impact: Low
• Frequency: Low

• 3 - Low

Linked to Story

Screen shot(s) and additional information

Here's a video showing me logged in as John Weaver, receiving a PN and following it, logging out, logging in as Judy Morrison, and being taken to John Weaver's message (which is, of course, an error for Judy).

Full JSON response for services related to issue (expand/collapse)

Ticket Checklist

• [ ] Steps to reproduce are defined
• [ ] Desired behavior is added
• [ ] Labels added (front-end, back-end, global, Health, relevant feature, accessibility, etc)
• [ ] Estimate of 1 added (for front-end tickets)
• [ ] Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)

[TKDickson]

Recommendation for the fix from Dylan -

when playing around in the Notification RQ branch fixing the duplicate api calls I found that we can clear those out with Notifications.removeAllDeliveredNotifications() and likely just need to call that line of code whenever we are done linking them somewhere in the app