Skip to content

Rewrite error serialization - #61

Merged
FrederikBolding merged 15 commits into
mainfrom
fb/fix-error-serialization
Apr 11, 2023
Merged

Rewrite error serialization#61
FrederikBolding merged 15 commits into
mainfrom
fb/fix-error-serialization

Conversation

@FrederikBolding

@FrederikBoldingFrederikBolding commented Oct 27, 2022

Copy link
Copy Markdown
Member

Rewrite error serialization to allow any error that conforms to the JsonRpcError JSON-compliant type.

If the error does not conform to this type, it will be wrapped in an Internal RPC error and the original error will be included as the data.cause. Any non JSON-compliant props of the error will be removed.

Fixes https://github.com/MetaMask/eth-rpc-errors/issues/51

@FrederikBolding
FrederikBoldingforce-pushed the fb/fix-error-serialization branch 4 times, most recently from 4fac448 to d92428bCompareNovember 2, 2022 12:02
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
@FrederikBoldingFrederikBolding changed the title Fix error serializationRewrite error serializationNov 3, 2022
@rekmarksrekmarks self-assigned this Nov 10, 2022
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
@FrederikBolding
FrederikBolding dismissed a stale review via 132112fMarch 9, 2023 10:06
@FrederikBolding
FrederikBoldingforce-pushed the fb/fix-error-serialization branch from 132112f to 5a145b0CompareMarch 9, 2023 10:08
@FrederikBolding
FrederikBolding marked this pull request as ready for review March 9, 2023 10:18
@FrederikBolding
FrederikBolding requested a review from a team as a code ownerMarch 9, 2023 10:18
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts Outdated
Comment threadsrc/utils.ts
// If the error does not match the JsonRpcError type, use the fallback error, but try to include the original error as `cause`
const cause = serializeCause(error);
const fallbackWithCause = {
...fallbackError,

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

drops non enumerable properties

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

What would you prefer then? Setting enumerable to true for fallbackError?

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

In my opinion, this wouldn't be an issue since we specify the fallback error and it includes the cause that may still have a stack.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Presumably what we'd want to do here is preserve the fallbackError as much as possible, mutating it only to add the cause property.

In this case the fallback error is already expected to be a "serializable object" though, right? So maybe we don't need to worry about non-enumerable properties. Though the JSDoc description should certainly clarify that expectation if that is the case.

Copy link
Copy Markdown
MemberAuthor

Choose a reason for hiding this comment

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

Yeah, I would expect it to be serializable according to the type. I can add it to the doc string

Comment threadsrc/utils.ts
Comment threadsrc/utils.ts
Comment threadsrc/utils.test.ts
@socket-security

Copy link
Copy Markdown

New dependency changes detected. Learn more about Socket for GitHub ↗︎


👍 No new dependency issues detected in pull request

Bot Commands

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@* or ignore all packages with @SocketSecurity ignore-all

    Pull request alert summary
    IssueStatus
    Install scripts✅ 0 issues
    Native code✅ 0 issues
    Bin script shell injection✅ 0 issues
    Unresolved require✅ 0 issues
    Invalid package.json✅ 0 issues
    HTTP dependency✅ 0 issues
    Git dependency✅ 0 issues
    Potential typo squat✅ 0 issues
    Known Malware✅ 0 issues
    Telemetry✅ 0 issues
    Protestware/Troll package✅ 0 issues

    📊 Modified Dependency Overview:

    ⬆️ Updated PackageVersion DiffAdded Capability Access+/- Transitive CountPublisher
    @metamask/utils@5.0.03.6.0...5.0.0network+47/-0metamaskbot
    typescript@4.9.54.7.4...4.9.5network, shell, environment+0/-0typescript-bot

    Gudahtt
    Gudahtt previously approved these changes Apr 11, 2023

    @GudahttGudahtt left a comment

    Copy link
    Copy Markdown
    Member

    Choose a reason for hiding this comment

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

    LGTM!

    @FrederikBolding
    FrederikBolding merged commit 8191913 into mainApr 11, 2023
    @FrederikBolding
    FrederikBolding deleted the fb/fix-error-serialization branch April 11, 2023 13:00
    rekmarks added a commit that referenced this pull request Oct 8, 2024
    #158)
    This ensures that non-empty string `error.message` properties of
    serialized errors are preserved by default, even if the serialized error
    is not [a valid JSON-RPC
    error](https://www.jsonrpc.org/specification#error_object). This
    behavior can be overridden by setting `shouldPreserveMessage: false`.
    In #61, our error serialization logic was considerably improved. One of
    the behavioral changes made at the time was to always overwrite the
    `message` property with that of the fallback error (practically always
    the "internal JSON-RPC-error"), regardless of whether a non-empty string
    message was present on the original error object. We have yet to ship
    this everywhere in our stack, in part because such a change may be
    breaking for our consumers. By reverting to the old behavior for the
    `message` property only, we avoid these potential breakages and improve
    the accessibility of potentially useful information to consumers (i.e.
    directly in the error message as opposed to buried in
    `error.data.cause.message`).
    Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

    Labels

    None yet

    Projects

    None yet

    Development

    Successfully merging this pull request may close these issues.

    Error serialization logic is faulty

    5 participants

    @FrederikBolding@kumavis@Gudahtt@Mrtenz@rekmarks