Closed grossb1 closed 3 years ago
The current hypothesis is that this was due to some internal testing, given the strange user-agent. Due to the fact the we've only seen a small number of occurrences we are going to assume this was not due to a functional problem and close:
19:30:56 web.1 |
{
"host": "4743b4c23f4e",
"application": "vets-api-server",
"timestamp": "2021-02-11T19:30:56.842776Z",
"level": "info",
"level_index": 2,
"pid": 84,
"thread": "puma threadpool 008",
"named_tags": {
"request_id": "3e98e24f-bed6-470d-ae88-cffe827e1c9d",
"remote_ip": "135.180.139.169",
"user_agent": "VAMobile/38 CFNetwork/1220.1 Darwin/20.3.0",
"ref": "688c65483890b0ebfb6d974a4674874114762630"
},
"name": "Rails",
"message": "Processing by Mobile::V0::AppointmentsController#index as */*"
}
As of this 02/10/2021 (02/03/2021-02/10/2021) there were 156 occurrences of this error.
/appointments/v1/patients//appointments
/var/VeteranAppointmentRequestService/v4/rest/direct-scheduling/patient/ICN//booked-cc-appointments
Two URLs are included because these end-points tend to get called in tandem. They also have the same exact number of occurrences.
Typically the user's ICN is included in this request
../patients/<ICN>/appointments
. Determine why ICN is not being populated in this class of errors.Team will investigate Prometheus, Cloudwatch and the vets-api code-base to determine root-cause of this issue.
Deliverables
Notes: There are other teams that call this service: