Rx: Have specific error handling for 'optimistic lock' errors

[TKDickson]

Description

As a veteran, I want to see my prescriptions and refill my meds, so that I can manage my health. However, we currently experience a fairly high error rate (5-7% were the latest numbers I saw) of "optimistic lock" errors that prevent veterans from using the Rx feature. Also, adding to the confusion, when when get these errors back we display a message of "you don't have any medications" which is incorrect.

As part of this story we want to:

• Create specific error-handling UI & workflow for this most-common error, especially since refreshing the meds list should often realistically work to actually return the med list for the veteran

Therese's hot take: something along the lines of “your pharmacy record is locked/unavailable/in use, but refresh and try again” with a refresh button.

Acceptance Criteria

• AC 1
• AC 2
• AC 3

Accessibility Requirements

• AC 1
• AC 2
• AC 3

Notes & Open Questions

• Dependencies/Roadblocks:

  • Any internal/external dependencies?
  • Test accounts needed?

• Does this require QA?

• Dev Notes:

An example of the charles proxy return for one of these errors, although there may be other codes they map to:

{
	"errors": [{
		"title": "Operation failed",
		"detail": "Something went wrong. Please try again later.",
		"code": "RX99",
		"source": "Error in fetching currentPrescriptions Object of class [gov.va.med.mhv.rxrefill.data.model.Request] with identifier [21904830]: optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [gov.va.med.mhv.rxrefill.data.model.Request#21904830]",
		"status": "502"
	}]
}

Ticket Checklist

• Acceptance criteria defined
• Labels added (front-end, back-end, feature)
• Linked to an Epic

[TKDickson]

@MekoHong this is pretty bare bones (I know what goes into bug tickets, but not what goes into other ticket types) but hopefully it's enough to document the work

[jperk51]

There are a couple other things that could cause 502's, but I don't think any of them should show that message. This could just be a copy issue? I would expect the error messaging to be more like "something went wrong". If we want to have the existing messaging then I would want to confirm what exactly the error looks like from MHV for someone that doesn't have prescriptions

[MekoHong]

@jperk51 @dumathane @TKDickson in our planning session, this is the ticket I believe we were referencing around the error code(s) we're receiving for RX and backend sending over as 502s. Is this the related issue or is it different? Slack message https://dsva.slack.com/archives/C018V2JCWRJ/p1678888786057119

[TKDickson]

@MekoHong yep this is the ticket!

[jperk51]

Andrew just finished some investigation and we figured out that the existing RX service we are using is remapping a number of errors from MHV into 502s. We can map these errors however we want. The correct thing to do would be to map the locking errors to 409s and the timeout errors to 408s. This would only solve the issue for future builds of the app where the FE is interpreting these error codes.

List of RX Errors before vets-api manipulates them:
https://docs.google.com/spreadsheets/d/1ji2LPqAY3NC3rP6ITW7a1dEWG7dInA5dWNeF3LtZMDU/edit#gid=0

[jperk51]

Created a ticket for updating the error handling on the backend #5246

[Sparowhawk]

@TKDickson We can limitedly interpret the BE error codes now. This may be better to wait until the custom error component is implemented and BE can just supply the copy to us.