BUG - 3 - All -Benefit summary and service verification letter stuck showing loading component when beneficiary data request fails

[theodur]

What happened?

When the request for fetching beneficiary data fails, the Benefit summary and service verification letter screen is stuck showing the loading component. This is caused by the logic in the onViewLetter function that gets called when a user tries to view the letter.

It's not clear whether we should show an error if the beneficiary data request fails, as the logic for generating the letter will still generate the letter if beneficiary data isn't available. It needs to be determined whether we should show an error when the request fails, or if we should still allow the user to view the letter without the beneficiary data included.

Specs:

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

Steps to Reproduce

• Throw an error in the getLetterBeneficiaryData thunk in the lettersSlice or mock an error from the /v0/letters/beneficiary endpoint with Charles Proxy.

• Navigate to the Benefits -> VA letters and documents -> Review letters -> Benefit summary and service verification letter

• Notice the loading component is stuck on the screen

Desired behavior

The Benefit summary and service verification letter should not be stuck on the loading component if the beneficiary data request fails.

Acceptance Criteria

• [ ] Determine whether an error should be displayed or the user should still be allowed to see the letter without the beneficiary data present
• [ ] Make necessary updates to handle failed beneficiary data in the correct way

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]

Hey @bischoffa - we're going to need UX decision on this part (below). I've seen a few bugs where there's been a splitting off UX ticket for that decision-making just recently, is there a formal process for that (who should spin up the UX ticket, where the bug ticket goes in teh meantime, ticket templates) that you know of? Should I ask a UX person instead?

[TKDickson]

Whoops. Decision needed on this part:

It's not clear whether we should show an error if the beneficiary data request fails, as the logic for generating the letter will still generate the letter if beneficiary data isn't available. It needs to be determined whether we should show an error when the request fails, or if we should still allow the user to view the letter without the beneficiary data included.

[bischoffa]

@TKDickson Thanks! Yep if there is a UX (other another discipline) descision needed I am breaking off a separate ticket.  PM owning bugs (right now me) is splitting out the UX ticket and coordinating with Jen to prioritize. 

As for the process, QA can scrub tickets as needed. Thoughts on if we modify the process so that if QA identifies UX decision is needed to then add the label blocked-ux? PMs can take care of anything after that.

[TKDickson]

@bischoffa sounds good! Will add the blocked-UX label and move to the blocked column (after the other scrub stuff is done) when we see them. That separate UX decision ticket is a good idea.

[timwright12]

@bischoffa @TKDickson any news on this one? Been blocked by UX for a while

[bischoffa]

@timwright12 not yet. UX has had other priorities as of now that fit into their bug work and tech debt.

[Sparowhawk]

@wavelaurenrussell if you could respond in this ticket instead of the other one that would be great lol

[timwright12]

@wavelaurenrussell @ala-yna ping for response on this ticket, seems blocked by UX

[wavelaurenrussell]

Can someone explain why this has a Blocked by UX label? What is the block?

[timwright12]

@wavelaurenrussell I think it's the second paragraph in the description @TKDickson called out:

It's not clear whether we should show an error if the beneficiary data request fails, as the logic for generating the letter will still generate the letter if beneficiary data isn't available. It needs to be determined whether we should show an error when the request fails, or if we should still allow the user to view the letter without the beneficiary data included.

[TKDickson]

The screen you're stuck on forever, if the beneficiary call errors out (never resolves into an error state):

[wavelaurenrussell]

Perfect thanks! I think the solution should still allow the beneficiary travel screen to load so that users can get their letter. And then we can present an Alert at the top that describes that the failure happened; you can still get your letter but things may be inaccurate.

Would this cover it? If so, I'll loop in Misty next.

[TKDickson]

@wavelaurenrussell yes it would. I think what would happen is you'd be able to generate a letter (with the right information/everything accurate), but not be able to pick what shows on it (aka it would default to showing all information)

That's a ~80% guess, but after this UI/front-end thing is resolved I could confirm it.