-
Notifications
You must be signed in to change notification settings - Fork 23
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
fix: ID-2650 Handle unknown or invalid refresh token error #2399
base: main
Are you sure you want to change the base?
Conversation
}).catch(); // User does not exist, don't initialise an eth signer | ||
}).catch(() => { | ||
// User does not exist, don't initialise an eth signer | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was where the error was not being caught - catch requires a function to handle the error
☁️ Nx Cloud ReportCI is running/has finished running commands for commit bb83e34. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution ✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
if (useCachedSession) { | ||
if (error instanceof Error) trackError('passport', 'login', error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think where the trackError
call was before made sense, but I think the right solution is to no longer surface unknown or invalid refresh token "errors" as errors. Maybe something like this:
} catch (error) {
// pseudo
if (errorIsUnknownOrInvalidRefreshToken) {
flow.addEvent('unknown or invalid refresh token');
} else {
trackError('passport', 'login', error);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only throw in the useCachedSession
scenario which is why I moved the track here - do you think we should track other errors caught here even if they do not throw and just ignore any related to the invalid refresh? I suppose this would highlight any errors thrown here that we might not be handling so I think that makes sense.
Hi👋, please prefix this PR's title with:
breaking-change:
if you have introduced modification that necessitates immediate adjustments by this SDK's users to their applications, clients, or integrations to avert disruptions to existing features or functionalities.feat:
,fix:
,refactor:
,docs:
, orchore:
.Summary
Detail and impact of the change
Added
Changed
Deprecated
Removed
Fixed
Security
Anything else worth calling out?