AC-api: Determine next user action for "technical" error codes

[wesrowe]

Description

User story

As a Veteran, I want any technical issue (error or delay/pending) with the Account Creation API to be resolved automatically or, if that's not possible, communicated as specifically to me as feasible, so that I understand what I need to do to resolve it and when.

Notes

• follow-on to Validate acct-creation API discovery against actual in staging #91876: for error codes that are not "user-action" (i.e., technical rather than requiring user to call MHV help desk)
• Mural area that breaks these out in greater technical detail, sourced from the API docs in confluence (PDF also available)
• UPDATE 12/6: This is the current understanding of the error codes. (Copied from Wes's work on Product Guide.) For ones that MHV Help Desk doesn't have a clear action to take, we need to investigate further 1) whether our app can take action (eg re-try) and 2) what more specific message can we provide to the user (e.g., "log out and in again" was made up by Wes).
• Figma of draft "technical" alert. Note that it mentions refreshing the page, that's adequate for the common 803 error.

Error Code	Cause	Triage approach
801	Multiple Active MHV Accounts found in MHV for user ICN and Deprecated ICN	MHV Help Desk: use the Profile Update button to resolve. If not resolved escalate HRC ticket to Tier 2.
802	ICN provided is not the Primary ICN	Could be caused in MHV back-end or other systems. Needs technical escalation.
803	For any other downstream MHV errors that stopped processing of the IAM Provisioning request in MHV	Veteran can try again later. Refreshing browser or signing out and in again should fix it unless there is a system outage.
804	User has a date of Death in MPI	MHV Account cannot be created if date of Death is accurate.
805	No active user account with ICN, but deactivated account found with ICN.	MHV help desk: reactivate their MHV account.
806	Multiple Accounts found with same Traits	MHV help desk: resolve manually.
807	User account found with Traits match, but MHV has a different ICN for that account	MHV help desk: resolve manually.
808	Invalid Token,  Missing Token Value	User should try logging out and back in again.
809	A field passed to the MHV API is mis-formatted or missing	User should try logging out and back in again.
810	Upgrade to Premium Failed	Veteran can try again right away.

Possible tasks:

Acceptance criteria

• For each error code, determined if calling MHV Help Desk is really the next best action, or is there something the user or our component should do - e.g., should we make an automatic re-try from our component?
• Drafted specific alert language for error codes where appropriate (e.g., "log out and in again")
• Documented appropriate triage recommendation for each error code if it reaches a help desk: e.g., what contact center at VA can help resolve this, how would they resolve it, etc. (see 801 for example)

[dcloud]

Slack thread seeking info FWIW

[wesrowe]

Updates:

I got the team's input in standup today 12/9 for the codes I wasn't clear on handling.

• 808 – signing out and in again should fix. However, with an invalid token it's very unlikely/impossible for a Veteran to reach any page in the health portal
• 809 – same, signing out/in should fix. very unlikely Veteran could reach portal with missing data.

A couple error codes (802 and 803) still needed input, so I reached out to Joe and got clarification in this slack thread.

I asked:

802, ICN provided is not the Primary ICN – is it the vets-api code that would have selected the non-primary ICN? or does the problem go back to MPI?
803, For any other downstream MHV errors that stopped processing of the IAM Provisioning request in MHV
– is this a transient problem that we should auto-retry? or is there something that a help desk could assist the Veteran with?

Joe responded:

1. thats the response from MHV. We call them with an ICN from vets-api and then MHV responds back saying the ICN isnt primary. Which can happen in rare cases but there was also a bug on the MHV side that they recently fixed that was causing this error to show up incorrectly from MHV

(I verified in DD that 802 is not a common error at this point in time)

3. yes you can retry the mhv account creation api call for this error but I wouldnt retry it too many times because sometimes these systems go down and retrying will only cause latency issues on our end. Id say retry one time per session
   Joe also provided this DD dash, where (scroll down) we can see the error codes in prod. 803 and 805 are very common, other codes seem very rare.

Analysis

1. 803 and 805 are the only common errors
2. 805 (deactivated) is a clear MHV HD scenario, so they will triage
3. 803 we should consider adding an automated retry. Joe mentions that "these systems go down sometimes" as a rationale for not retrying. I'm looking at it a little differently: our call from the portal is in fact a "second try" – either the original sign-in call to ACapi or our first call to it should get a successful response. Does the fact that a user is getting 2 tries make the likelihood of an 803 extremely unlikely?

cc @kjsuarez @mcarterA6

[sterkenburgsara]

808 & 809 - blocked access is only going to be true within apps affected by account creation API which are medical records, meds, messages. Users can still get to many pages in the health portal, including: landing page, appointments, supply re-order, payments links, etc.

Here is the API logic diagram again if helpful to jog memories. Account Creation API creates an MHV-Identifier, which will allow access to apps in the very last box (bottom of the flow). A missing MHV-Identifier will mean no access to these tools.

[wesrowe]

Done! Closing