You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TKDickson opened this issue
Aug 15, 2024
· 3 comments
Assignees
Labels
bugUsed to identify a bug ticket that will be worked through the bug processClosed - Deployed/FixedglobalIssues for the global teamQATickets require QA work / reviewQA 1QA work sized as a 1sev-3Lowest bug severity level based on QA bug severity scale - QA to assign this
We were throwing tons of (ultimately non-useful) errors for a non-JSON response during login - added code in #9266 to get rid of those false positives.
However, we should make sure that if we are receiving responses that have a content type in their header that isn't application/json, we have monitoring to be aware of it and be able to communicate with owning teams if it happens in the future.
Binny came up with something like this as a proposal (and I think that would be a good approach! and yes of course with a viable event name instead of this one):
Added either to the relevant feature epic (if found during new feature implementation), or the relevant team's bug epic (Global, Health & Benefits, API, QART)
The text was updated successfully, but these errors were encountered:
TKDickson
added
bug
Used to identify a bug ticket that will be worked through the bug process
global
Issues for the global team
QA
Tickets require QA work / review
sev-3
Lowest bug severity level based on QA bug severity scale - QA to assign this
labels
Aug 15, 2024
Did a Slack huddle with Binny to confirm the analytics event was firing as designed (screenshot of terminal in PR attached to this ticket), and didn't reintroduce the false alarm JSON error fixed in #9266.
Also confirmed that I can still do initial (UN/PW) and subsequent (biometrics) login on iOS and Android.
@dumathane and I met today - this code has been live for two weeks, and we haven't logged a single vama_9385_api_cType event. This is a good sign - scheduling another meeting for a month out, if we still don't see anything logged to this event, we're going to retire it.
bugUsed to identify a bug ticket that will be worked through the bug processClosed - Deployed/FixedglobalIssues for the global teamQATickets require QA work / reviewQA 1QA work sized as a 1sev-3Lowest bug severity level based on QA bug severity scale - QA to assign this
What happened?
We were throwing tons of (ultimately non-useful) errors for a non-JSON response during login - added code in #9266 to get rid of those false positives.
However, we should make sure that if we are receiving responses that have a content type in their header that isn't application/json, we have monitoring to be aware of it and be able to communicate with owning teams if it happens in the future.
Binny came up with something like this as a proposal (and I think that would be a good approach! and yes of course with a viable event name instead of this one):
Specs:
Steps to Reproduce
Desired behavior
Acceptance Criteria
Bug Severity - BE SURE TO ADD THE SEVERITY LABEL
See Bug Tracking for details on severity levels
Linked to Story
Screen shot(s) and additional information
Full JSON response for services related to issue (expand/collapse)
Ticket Checklist
The text was updated successfully, but these errors were encountered: