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

[FEATURE] Improved Cadence Error Reporting #1891

Closed
JeffreyDoyle opened this issue May 28, 2024 · 1 comment · Fixed by #1893
Closed

[FEATURE] Improved Cadence Error Reporting #1891

JeffreyDoyle opened this issue May 28, 2024 · 1 comment · Fixed by #1893
Assignees
Labels

Comments

@JeffreyDoyle
Copy link
Member

Issue to be solved

When a transaction is reverted, due to a Cadence error emitted during its execution, the result of the error is not currently passed to the consumer of FCL in a consumable way. Developers today only get the error text output from the transaction, and are left to their own to extract the error type in some meaningful way.

Suggest A Solution

When a transaction is reverted, and there is an error emitted as part of the execution of the Cadence transaction, FCL should pass that error to the consumer in some consumable way.

There are several existing error codes standardized by the Flow protocol: https://github.com/onflow/flow-go/blob/1ac121d17c75c2c949fa34d6e956b89fa0499d7b/fvm/errors/codes.go

If the error emitted as part of a Cadence transaction reflects one of these standardized error codes, FCL should make that error code available to the consumer.

For other non-standard error types, FCL should make those available to the consumer as well.

What are you currently working on that this is blocking?

No response

@jribbink
Copy link
Contributor

jribbink commented May 28, 2024

My thought here is to create a FlowError type, roughly like:

// todo: maybe better/more specific messaging?
class FlowError extends Error {
    code: number
    message: string
    constructor(code: number, message: string) {
        this.code = code
        this.message = message
    }
}

class CadenceRunTimeError extends FlowError {
    constructor(message: string) {
        super(1101, message)
    }
}

...etc...

Then any eligible transaction result errors will get mapped -> FlowError type if possible. And a developer can now do the following:

mutate(...).then(txId => fcl.tx(txId).onceSealed()).catch(e => {
    if (e instanceof CadenceRunTimeError) {
        // this is a Cadence runtime error, I can do something special with it...
    }

    // Or, maybe they just want to check if it is any type of FlowError
    if (e instanceof FlowError) {
        // do something
    }

    // right now, this error is just a raw string which is not very usable/identifiable without the developer understanding every error code & how to parse from access node error string, this makes it much easier.
})

thoughts?

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

Successfully merging a pull request may close this issue.

2 participants