Direct Scheduling Error when veteran double booking; Bad error message & no way for user to resolve/edit

[marcynadeau]

Steps to recreate

1. In VAOS try to direct schedule a VA appointment at the same time or during the same interval as an existing appointment.
2. VAOS displays an error telling the user something went wrong and to try again. We’re sorry. Something went wrong when we tried to submit your appointment and you’ll need to start over. We suggest you wait a day to try again or you can call your medical center to help with your appointment.
3. The problem is that if the veteran starts over to direct schedule or tries again or waits a day, the same thing is going to happen. This error message needs to be changed so that veteran knows that they are trying to schedule at the same time as an existing appointment or some other verbiage but telling them to try again is useless and will lead to the same error.
4. Also the fields there is no way for the user to exit from this screen. No buttons or anything. The user has to use the navigation path in the top portion of the screen and not all users are that tech savvy. Note the user is only allowed to edit two fields (reason for appointment and contact details) on this page and neither of these two data fields do anything to resolve the error.

(Note the same issue presents if VA appointments are overlapping. An existing appointment at 0800 that is 60 minutes long and then user tries to book an a new appointment at 0830. Same error message displays in dev tools.)

See attachment.

[laurenernest]

@jbalboni From a technical perspective, does this overlapping appointment check have to happen on click of confirm appointment at the final step?

[jbalboni]

@laurenernest We on the FE have no way of knowing this ahead of time. This is a var-resources error, it needs to be fixed in the backend. They need to:

1. Send us a 400 level error when this happens, instead of a 500 error
2. If possible, don't send us timeslots that a user can't schedule into because there's an overlapping appointment

[laurenernest]

@saneshark Can you find out how often this occurs?

[laurenernest]

@grossb1 Can you create a BE ticket to find out how often this double booking error occurs?

[jbalboni]

@laurenernest This is just for direct scheduling, so it's not happening in production, just staging.

[laurenernest]

Do we have data from when direct scheduling was on though? Or was that too short of a time?

[jbalboni]

@laurenernest I think it was too short of a time (it was on for a few weeks, I think) and it was also long enough ago that we don't still have the logs, though @saneshark or @grossb1 could confirm that.

[jbalboni]

Here is another similar error, for a user who books a slot that is occupied between them choosing it and them submitting the appointment:

 {"errors":[{"title":"Bad Gateway","detail":"Received an an invalid response from the upstream server","code":"VAOS_502","source":{"vamfUrl":"https://internal-dsva-vagov-staging-fwdproxy-1821450725.us-gov-west-1.elb.amazonaws.com:4463/var/VeteranAppointmentRequestService/v4/rest/direct-scheduling/site/983/patient/ICN/1013120820V528557/booked-appointments","vamfBody":"{\"id\":\"037fb5b5-7e4f-453e-b5fc-b3fb1477b5d2\",\"traceId\":\"693ddfc1dff9f29f\",\"code\":500,\"message\":\"Could not book appointment from VistA Scheduling Service\",\"errorCode\":7001,\"detail\":\"400: {\\n  \\\"code\\\" : 400,\\n  \\\"message\\\" : \\\"813 NO_OPEN_SLOT:Invalid appointment. RESULT(0)=APTNOST^NO OPEN SLOTS THEN^1\\\",\\n  \\\"id\\\" : \\\"9d3f9dbf-b79c-418d-8134-8b58ddccaba7\\\",\\n  \\\"errorCode\\\" : 400\\n}\",\"meta\":{\"upstreamErrorSource\":\"vista-scheduling-service\"}}","vamfStatus":500},"status":"502"}]}

[jbalboni]

@saneshark @grossb1 Both the error I just posted and the error in the original description are interpreted by vets-api as 500 errors, rather than as 400 level errors. Is that because we're doing something wrong in vets-api, or because the status isn't correct from VAMF?

[saneshark]

So in this case VAMF is returning a 500 error. This should be a 409 conflict much like they return for appointments that fail cancellation.

We can temporarily parse the error payload and return a 400 level error much like we did when appointments#cancel was broken, but I really think this needs to be resolved at the VAMF level -- this should not be a 500 level error from VAMF.

[saneshark]

@grossb1 Lets put together a report we can run daily that fetches this type of issue from Rails logs.

It will be a 500 level exception coming from VAMF to /var/VeteranAppointmentRequestService/v4/rest/direct-scheduling/site/<SOME SITE>/patient/<SOME ICN>/booked-appointments

We won't observe any in production, but we should be able to observe some on staging. I think you'll need to change the constant for where the logs are stored to staging to validate the script is working correctly, but we'll want to verify this type of thing in production when we enable covid sheduling.

[jbalboni]

@saneshark Are you going to create a VAOSR ticket for getting this fixed on the VAMF side?

[saneshark]

Opened https://issues.mobilehealth.va.gov/browse/VAOSR-1701

[saneshark]

@jbalboni how soon are we likely to encounter this in production? If the fix in VAMF will take longer we might need to discuss tomorrow on SoS a way whereby we can parse the JSON body and return something other than 502 to the FE, interpret the 500 received as a 409 as a temporary stopgap until they can fix.

[jbalboni]

@saneshark I think it's something that could potentially come up quickly. Marcy pointed out that if we have a lot of people try to book a limited number of slots, the risk of the slot being filled between the calendar page and the final submit page goes up. I think it probably makes sense to update asap, and also make sure that we have a way on the FE do tell that it's specifically due to a slot being filled, since I could see us wanting to be specific about that.