BUG - sev-3 - All - Don't do API call for PN prefs if sid is null

[TKDickson]

What happened?

We do a call for a veteran's PN preferences when they navigate to the Notification preferences page, regardless of if they have a SID or not. When they haven't been registered successfully for push notifications, that call looks like this: /mobile/v0/push/prefs/null and will always fail (should instead be /mobile/v0/push/prefs/######with their ID if it's going to have a chance of succeeding).

Specs:

• Device:
• OS:
• User Account:
• Accessibility State:

Steps to Reproduce

Can get this on Android by failing/blocking the /mobile/v0/push/register calls during login (definitely initial login, and subsequent logins if you've never turned on PN), then going to Profile > Settings > Notifications.

Desired behavior

We should just not make a failing call - can we handle that error/edge state better on the notification preferences screen? Ex - check for ID, make a call to register if they don't have one, then call for preferences.

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: High Low
• Frequency: High Low

• 3 - Low
• 2 - High
• 1 - Critical

Linked to Story

Screen shot(s) and additional information

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, 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 bug epic

[TKDickson]

At my WIP limit; marking as blocked

[TKDickson]

Picking this up, removing blocked label

[TKDickson]

Picking this up, removing blocked label

[TKDickson]

May not be able to test this at all for Android (how charles + webview login don't play nicely together on that platform).

For iOS, I believe we should be displaying the error message from ticket #1656 under the following circumstances, but currently are displaying the PN prefs screen, empty of PN pref toggles (see screenshot after circumstances).

• Log into iOS and, on the native 'can we send you PN' popup, select yes
• Use Charles Proxy to fail that call somehow (I'm just having Charles drop the connection)
• Go to Profile > Settings > Notifications (at which point we are correctly NOT calling the 'prefs' API, because this person isn't registered; we are also correctly NOT showing the "go to your app settings to turn on PN" because this user has done so).
• At this point, I imagine ideally we would (under these circumstances) attempt to send the registration call again, and then display an error message if it didn't go through.

Screenshot of what screen actually looks like:

We do call the PN registration API call during authentication (or biometric 'session recovery'), so these users probably wouldn't be in PN limbo indefinitely. But we could make their limbo state clearer, for sure.

[TKDickson]

@theodur two things:

• I'm seeing the error during the scenario above (good) but pressing the refresh screen button, in iOS, is not actually resending the API calls. I see you have a commit specifically around that, so that's extra puzzling.
• I'm also seeing the error above in a scenario when I should NOT see it - specifically, when I opt-out of push notifications during initial login for iOS. In this scenario, I'd expect to see the existing "hey you need to go opt into push notifications in your app settings" info on the notifications screen.

[theodur]

Assigned Dylan to this since this is now part of the PR for #8253

[TKDickson]

Have been blocked on this since Tuesday - there's a reverse proxy server somewhere in the staging notification ecosystem that's not playing nicely. Hopefully resolved today.

[TKDickson]

DSVA support thread is resolved and I've confirmed I can successfully register for notifications, as well as fetch preferences, from upstream servers. This is unblocked and I can start working on it tomorrow.

[TKDickson]

On a build from this branch from today, we are correctly not calling the preferences endpoint if SID is null (aka they have not yet registered for push notifications)

[TKDickson]

Adding a comment to myself mostly - reconfirming that in the latest RQ branch, everything I wanted, all of the weird behaviors documented originally & in comments in this ticket, are fixed and working as expected. No further testing needed on this ticket, unless mandated by fixes to the other stuff going back and forth.