Validate acct-creation API discovery against actual in staging

[wesrowe]

Description

Since initial discovery work (Engineering: Carlos; UX: Sara), the Account Creation API architecture shifted. Joe Niquette led those conversations and updated the identity team's implementation plan, but we don't completely know what that will look like. Once identity has something ready for our team to look at in staging, we need to:

• compare the implementation to what we had modeled previously during discovery efforts,
• understand the differences,
• determine whether or not the error states we previously identified as needs for the FE are still technically feasible.
  • If not, we may need to edit our UX strategy

User story

As a Cartography team member, I want to check our team's understanding of the Account Creation API from discovery against the actual implementation in Staging. Does it work as expected?

Notes

• Discovery Mural
• previous engineering discovery ticket
• Other previous ticket about documenting flows
• Technical Account Creation API specs
• Identity team example request body response for API errors

Possible tasks:

UX:

• Evaluate if the Mural (above) is still accurate
• Update it if not
• What errors are still possible with amended API architecture? If not all of them can be captured anymore, can enough detail be communicated to users that they will understand next steps & what the problem is?
• Have conversation w/ MHV Access + Portals team about any content they may need within these alerts in order to triage them to the place if a Veteran calls for help re: an API error.
• Iterate on alerts following conversation with MHV Access + portals team
• Connect with identity to make sure the error codes that require user action are available from their team (if. not,re-map them to new codes + circle back to notify Carnetta's team of the new error code numbers for their database)

Eng:

• Getting hands on an implementation model (from identity team or other)
• Are we getting clear enough error data to display alerts indicated in the Mural (above, under Notes section)
• If we need to display errors in another team's space or on a benefit hub page, what is our plan for doing that? Who will do the work and what people need to be involved?
• Any issues identified have been communicated back to identity team (Joe Niquette) and/or MHV API team as needed

Acceptance criteria

• Have an accurate diagram of the real-life implementation the Account Creation API
• We've mapped exactly what data/errors will trigger alerts in the FE user experience
• UX has gotten feedback/information from MHV Portals/Access team (Carnetta)
• UX understands how to use these errors to create meaningful alerts for the FE UX
• We know what teams to work with / get validation on our plan for related alerts in the FE experience
• Next steps are ticketed

[fmccaf1]

Mural link

[sterkenburgsara]

Update: Some developments in Slack (thread 1 and thread 2) are asking questions about the purpose of the Account Creation API, which seem to be different than what our team previously understood. Sara will try to draw a diagram of what we feel like we know? And iterate on it with Carlos, then the Identity team, and hopefully we can get to a shared understanding of how pairing with MHV-IDs works now and whether or not that will change with the account creation API. There also appear to be bugs that Joe & Trevor are identifying in logs - they're working out now what's causing those.

We believe a sync with someone from each of Carnetta's MHV team, VA.gov identity, CAIA, and Cartography within the confines of this sprint will be beneficial to ensure a shared mutual understanding of this landscape. Will try to connect with Joe and schedule something when he is back in the office next week.

[sterkenburgsara]

Update: Carlos and I synced yesterday (10/1/24) since he has access to the code for the Account Creation API and we were able to review the setup/architecture. Sounds like it is not yet implemented on VA.gov and there are a few outstanding questions.

We remapped the architecture that Carlos is seeing in the code in Mural here (see area with a green background) and believe we can still serve up the same FE alerts/errors that we had previously hoped for. There will be some complexity though in drawing up a plan around how affected apps & their teams should implement these alerts on their own applications and sharing that out with stakeholders. The implementation of any of this logic on the landing page should coincide with implementation work across the entire health portal, including all side-door entry point options.

@carlosfelix2 is validating our model with the identity team and asking them our outstanding questions. Some testing will probably be needed in staging to answer those q's. For now, Sara will create draft alerts based on our understanding of the API and will diagram options for routing in the tool applications. Once identity implements this API, we can test the validity of everything in staging and tweak things as needed. Once we have a good set of drafts and alignment with Identity team, we'll need to share out options with OCTO stakeholders over the affected tool teams and come up with an implementation strategy for the portal. Ticketing the shareout / alignment / implementation strategy work for the backlog now.

[sterkenburgsara]

Update: added an A/C to sync with MHV-Portals access team around content they may need within these alerts to successfully triage them to the right place if a user calls for help re: an API error. That sync is scheduled for next Monday, 10/28.

[sterkenburgsara]

Update: information about SM in Slack here validates that we should not need a unique alert / separate treatment fo the SM account creation aspect of the Account Creation API. Removed this error/alert pair from our drafts.

Synced with Carnetta's team on 10/28 about alert content we prepped over the last month, but found out that we very much do need to capture more nuanced error states that could be coming back from teh API. Will need to rearchitect an alert plan that keeps to the smallest # of alerts to minimize complexity. Sara will map out the errors that are backend (not user facing) and errors that do require action from the user. We'll then take those alerts to Joe and see if the alert ID numbers are available from their team or if we need to re-map them to unique numbers not already used by identity. I hope to pull @fmccaf1 into this one for some help thinking through it.

[sterkenburgsara]

cc @underpaid1ntern @bcaldwe11

[sterkenburgsara]

Update

@bcaldwe11 got confirmation from Haritha that we have the correct 4 error codes to focus on in FE alerts <img width="1584"

User-action-required error codes:

Other:

Identity team posted in Slack today with rollout plan & timeline for the API's implementation w/ sign-in

[sterkenburgsara]

Update: confirmation from Riley Anderson (identity team) in Slack here that all error codes are accepted by identity team and do not require re-mapping. They will finalize documentation around the error code responses tomorrow (daily deploy) after they are tested.

[dcloud]

If we need to display errors in another team’s space or on a benefit hub page, what is our plan for doing that? Who will do the work and what people need to be involved?

I could suggest a plan for displaying errors in other applications: create a shared component, get teams to use it. This is similar to how downtime alerts work, where there is a "platform" component that application teams are told to add to their SPA app.

However, it sounds like for the errors that have no actions for veterans to take, we’re limited to a “we’re aware of the issue, please check back later” approach for displaying errors

[wesrowe]

I caught up with Sara. It seems like what we need is a error code-by-code evaluation:

• if it's a Veteran-facing error (ie call help desk) we already understand from Carnetta what to tell users.
• otherwise, we need to know whether the Identity/sign-in app is going to retry, whether that code (if retry doesn't resolve) will be cached (so that a Verteran can't fix it by retrying), etc. And ultimately, do we have to tell the Veteran about those ones too.

[wesrowe]

also, I want to note that in this comment thread on the canvas, Joe N revealed that there will be a pending status that could drive, e.g., a loading spinner:

one more thing I wanted to mention, we have a pending completion status for the mhv account creation api and it is our expectation that app teams on va.gov will read this when appropriate and show a loading screen of some type until the call to the mhv account creation api completes

[sterkenburgsara]

Per standup, moving this to blocked until identity wraps testing w/ Account Creation API & is ready for feedback from our team.

[wesrowe]

Lainey (PM from Identity) shared this DD dash in response to my request for the data they saw in their 1-hour prod test. An engineer might want to look at it.

[wesrowe]

Closing – never did anything with this, API made it to prod before we investigated.