feat: unsupported transaction error fallback #823
Merged
Conversation
This file contains 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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
aforaleka
force-pushed
the
handle-untranslated-error-fallback
branch
from
408e367 to
3719405
Compare
aforaleka
force-pushed
the
handle-untranslated-error-fallback
branch
from
3719405 to
377a6bb
Compare
aforaleka
force-pushed
the
handle-untranslated-error-fallback
branch
from
9302e10 to
2becc0b
Compare
aforaleka
force-pushed
the
handle-untranslated-error-fallback
branch
from
2becc0b to
d86b896
Compare
| * Failed Query results (i.e., those starting with "Query failed") are matched via the error message, defaulting to "Unknown query result error". | ||
| * Unmatched errors will display the actual error message. | ||
| */ | ||
| export const stringifyTransactionError = (error: any): string => { |
There was a problem hiding this comment.
[q] does broadcasterror cover all abacus cases? i'm curious as to whether or not this will also fix the onboarding/offboarding modal errors
There was a problem hiding this comment.
this is where transaction errors are parsed!
that specific error in the slack channel is a broadcast error, so i think it's just because it wasn't passed through that function
src/hooks/useSubaccount.tsx
Outdated
| @@ -375,7 +376,7 @@ const useSubaccountContext = ({ localDydxWallet }: { localDydxWallet?: LocalWall | |||
| if (success) { | |||
| onSuccess?.(data); | |||
| } else { | |||
| onError?.({ errorStringKey: parsingError?.stringKey }); | |||
| onError?.(getValidParsingErrorParams(parsingError)); | |||
There was a problem hiding this comment.
[nit] should this function be named getValidOnErrorParamsFromParsingError? since what we're getting is the onErrorParams from the parsing error?
yogurtandjam
approved these changes
Jul 22, 2024
aforaleka
force-pushed
the
handle-untranslated-error-fallback
branch
from
fe28a1b to
d4125e2
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
context: it's possible that the stringkey we pass from Abacus might not exist in localization, since we aren't translating protocol errors 1:1. example. other than just translating all error codes and catching all possible query results (which is not sustainable), we should fallback to show some error message that is relevant
stringifyTransactionError, because when a normal Error is thrown (e.g. query update failure), JSON.stringify will not workerrorStringKey?: stringtoerrorParams?: ErrorParams, the latter includes a potential error string key and a fallback error messagefallbackparam, so when the string key isn't valid (part of STRING_KEYS), we should explicitly define fallback string. this is kinda optional so open to thoughts!before, query result failure (e.g. failure during subaccount transfer) will show no error strings. after:
