QA investigation: PN deeplinking into feature in downtime

[TKDickson]

If a veteran taps on a push notification for a feature that's currently in downtime (more on the variations of that below), are we handling it reasonably well? We're not sure that we've investigated this (definitely recently, maybe ever)

Features that have PN currently:

• messages (we can test this)
• appointments (we generally can't test this well :sad: )

Ways that I can think of that features are down:

• Maintenance window active at the moment the PN is tapped
• Maintenance window becomes active very shortly after PN is tapped
• Availability Framework is active for the page deeplinking to (I assume AF use case 2 will be locked down successfully, but.... I am skeptical about just AF use case 1. My guess is that we may need to change our AF guidance to say "if you're going to put UC1 on a deeplink-able screen, you also need to do UC2 specifically to cover push notifications")
• API is returning various errors

[TKDickson]

I was very torn whether this is global (PN, downtime) or Health (the actual features that can send PN, likely place where we'd need to implement fixes). As this is primarily QA, whoever gets to it first, gets to it first.

[bischoffa]

Removing QA and Release team label. This is a a global feature so Global will need to prioritize this within their own bug management epic