LG-14464: Show warning CTA on ThreatMetrix API exception#11459
Merged
LG-14464: Show warning CTA on ThreatMetrix API exception#11459
Conversation
lmgeorge
added
status - ready for review
ruby
lmgeorge
commented
Nov 5, 2024
Contributor
Author
There was a problem hiding this comment.
A/N: I've only ever found 2 variants of the actual exception message sent to us, but didn't think a stricter match was really necessary as we don't inspect the exception message at all.
lmgeorge
changed the title
matthinz
reviewed
Nov 6, 2024
n1zyy
approved these changes
Nov 8, 2024
Contributor
n1zyy
left a comment
n1zyy
left a comment
There was a problem hiding this comment.
I hadn't realized how complex this logic was! I like the pattern of a thorough PR description here. Looks good to me!
matthinz
reviewed
Nov 8, 2024
Contributor
There was a problem hiding this comment.
Using the ResultAdjudicator directly here is a Good Idea
**Why** * The "internal error" view displayed during IdV is a last resort view. Prior to this change, this view was also shown when we received a ThreatMetrix API response that included an exception message. * Showing the internal error view for an unknown exception raised by the ThreatMetrix API is not useful for the subject undergoing proofing and it obfuscates the action that can be taken by either the proofing subject or the support agent investigating the identity resolution errors. **How** * Added a logic branch to the routing handling of `Idv::VerifyInfoConcern#idv_failure` that still preferences the actionable error views (i.e., ssn_failure, rate_limiter, etc.), which is eventually called by both Idv::VerifyInfoController and Idv::InPerson::VerifyInfoController * Updated the Idv::VerifyInfoController spec to examine the expected routing and the expected shape of the ThreatMetrix API exception response. As the exception message is an arbitrary unstructured String, we do not test for specific values and instead ensure that the *shape* of the response in our analytics meets a minimum conformance in structure and value types. **Notes** * This is a difficult to replicate error as it relies on blackbox behavior exhibited by our vendor APIs. changelog: Internal, IdV resolution, Error routing for vendor API exceptions
…xception scenario
lmgeorge
force-pushed
the
lmgeorge/LG-14464
branch
from
cc66d80 to
4298aa1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The "internal error" view displayed during IdV is a last resort view. Prior to this change, this view was also shown when we received a ThreatMetrix API response that included an exception message.
Showing the internal error view for an unknown exception raised by the ThreatMetrix API is not useful for the subject undergoing proofing and it obfuscates the action that can be taken by either the proofing subject or the support agent investigating the identity resolution errors.
How
Added a logic branch to the routing handling of
Idv::VerifyInfoConcern#idv_failurethat still preferences the known actionable error cases (i.e., ssn_failure, rate_limiter, etc.), which is eventually called by bothIdv::VerifyInfoControllerandIdv::InPerson::VerifyInfoControllerUpdated the Idv::VerifyInfoController spec to examine the expected routing and the expected shape of the ThreatMetrix API exception response. As the exception message is an arbitrary unstructured String, we do not test for specific values and instead ensure that the shape of the response in our analytics meets a minimum conformance in structure and value types.
Notes
changelog: Internal, IdV resolution, Error routing for vendor API exceptions
🎫 Ticket
Link to the relevant ticket:
LG-14464