Conversation
Still needs some work on the error responses when there are unexpected USPS failures
changelog: Internal, In-person proofing, stop trigger on-call paging for expected usps facilities failures
eileen-nava
left a comment
eileen-nava
left a comment
There was a problem hiding this comment.
Good work. Approved!
| analytics.idv_in_person_locations_request_failure( | ||
| api_status_code: 422, | ||
| exception_class: err.class, | ||
| exception_message: err.message, | ||
| response_body_present: err.respond_to?(:response_body) && err.response_body.present?, | ||
| response_body: err.respond_to?(:response_body) && err.response_body, | ||
| response_status_code: err.respond_to?(:response_status) && err.response_status, | ||
| ) |
There was a problem hiding this comment.
I know this was an urgent change but I wonder if we can leverage something inside of Analytics class that pulls out relevant info from what looks like a pretty standard interface for this err variable.
I'm hoping for some "decorator" style patterns (or something) to help prevent bloat in these controller methods. Most of the code here is error handling :)
Happy to open a ticket/refactor later if that makes sense
There was a problem hiding this comment.
@allthesignals I like that idea -- will you create a ticket for it? We do some similar things in the proofing results job and I wonder if there's a better/more general way to do it, but a way that prevents PII from being logged
There was a problem hiding this comment.
rescue_from looks interesting.
@allthesignals I like that idea -- will you create a ticket for it? We do some similar things in the proofing results job and I wonder if there's a better/more general way to do it, but a way that prevents PII from being logged
Sure thing!
There was a problem hiding this comment.
I agree, that's a great idea. Thanks @allthesignals! 🎉
sheldon-b
deleted the
sbachstein/lg-8776-change-500-errors-to-4xx-errors-to-prevent-pages
branch
…7726) * Begin returning 422 for expected usps failures Still needs some work on the error responses when there are unexpected USPS failures * Annotate which requests are expected * Remove todo comment changelog: Internal, In-person proofing, stop trigger on-call paging for expected usps facilities failures
4 participants
🎫 Ticket
LG-8776
🛠 Summary of changes
Update the POST /verify/in_person/usps_locations endpoint so that common USPS failures result in a 422 response code to the front end instead of 500. This is to prevent appdev on-call from being paged. There are so few requests to the endpoint that a very small number of common failure types cause the on-call engineer to be paged.
We attempt to rescue common USPS errors and return a 422 for them which won't cause the on-call engineer to be paged. Other types of errors will continue to raise a 500 and cause a page. I found these types of failures when looking in the prod analytics events logs over the past 6 days:
📜 Testing Plan
Provide a checklist of steps to confirm the changes.
arcgis_search_enabled: true/verify/doc_auth/document_capture#locationpage and submit any address to simulate a failure👀 Screenshots
If relevant, include a screenshot or screen capture of the changes.
User experience of timeout error (unchanged)