Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(IT Wallet): [SIW-2022] Increased serialization for unexpected errors during eID issuance #6770

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

RiccardoMolinari95
Copy link
Collaborator

@RiccardoMolinari95 RiccardoMolinari95 commented Feb 28, 2025

Short description

This PR aims to enhance the reason, in the Mixpanel tracking, for errors during eID issuance that fall under IssuanceFailureType.UNEXPECTED .

Some unexpected errors in the reason field on Mixpanel report as {"jsEngine":"hermes"}. Unfortunately, this error is not descriptive, making it difficult to understand what the actual issue was.

List of changes proposed in this pull request

  • Added a check within the trackItwIdRequestUnexpectedFailure function to verify if failure.reason is empty
    If failure.reason is empty, the serializeFailureReason function (already used in the useItwFailureSupportModal hook) is utilized; otherwise, the current behavior is maintained.

How to test

Testing with Non-Empty Object

  • Using io-react-native-wallet package locally, you can simulate an unexpected error by throwing
    throw new AuthorizationIdpError("access_denied", "ErrorCode nr21: Timeout during user authentication");
  • The error is unexpected and the reason is the same before and after the change
    {"code":"ERR_IO_WALLET_IDENTIFICATION_RESPONSE_PARSING_FAILED","error":"access_denied","errorDescription":"ErrorCode nr21: Timeout durante l'autenticazione utente","jsEngine":"hermes","name":"AuthorizationIdpError"}

Testing Serialization Enhancement

  • I was able to replicate the situation described in the support tickets using Charles Proxy, where the error was Network request failed. In detail, the error appears as {"reason": [TypeError: Network request failed], "type": "UNEXPECTED"}. Previously, this error was reported on Mixpanel with the reason as {"jsEngine":"hermes"}.
  • This type of error, along with others in Mixpanel that have {“jsEngine”: “hermes”} as reason, probably has an empty object as failure.reason, but failure.reason.message is populated. With the recent changes, the reason on Mixpanel should now correctly show the reason

Copy link
Contributor

PR Title Validation for conventional commit type

All good! PR title follows the conventional commit type.

Copy link
Contributor

github-actions bot commented Feb 28, 2025

Jira Pull Request Link

This Pull Request refers to Jira issues:

Copy link

codecov bot commented Feb 28, 2025

Codecov Report

Attention: Patch coverage is 0% with 4 lines in your changes missing coverage. Please review.

Project coverage is 51.04%. Comparing base (99a2fbc) to head (9c80283).
Report is 4 commits behind head on master.

Files with missing lines Patch % Lines
...es/itwallet/issuance/hooks/useEidEventsTracking.ts 0.00% 4 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #6770      +/-   ##
==========================================
+ Coverage   41.94%   51.04%   +9.10%     
==========================================
  Files        1429     1583     +154     
  Lines       29960    32723    +2763     
  Branches     6662     7355     +693     
==========================================
+ Hits        12566    16703    +4137     
+ Misses      17364    15973    -1391     
- Partials       30       47      +17     
Files with missing lines Coverage Δ
...es/itwallet/issuance/hooks/useEidEventsTracking.ts 5.26% <0.00%> (-0.99%) ⬇️

... and 448 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e88f105...9c80283. Read the comment docs.

* To maintain compatibility with the existing failure tracking, we keep the original `failure` object when `failure.reason` is not empty.
*/
return trackItwIdRequestUnexpectedFailure(
!failure.reason || Object.keys(failure.reason as object).length === 0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is no failure.reason does it make sense to call serializeFailureReason? There should be nothing to serialize.

And do we really need to cast as object?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants