You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the Flow protocol side, ANs would like ENs to include errors into execution results, so they can serve requests without additional effort (e.g. re-execution of transaction(s)).
Currently, Cadence produces fine-grained errors, which are very detailed. Changes to the Cadence implementation commonly change errors (e.g. renaming of error type, change in error details, change of error message).
The nature of detailed/fine-grained and such changes increase the likelihood of execution forks, as an EN may produce a semantically equivalent error (e.g. type-checking of a contract failed), but the specific details of the error might be slightly different.
Suggested Solution
The content you are editing has changed. Please copy your edits and refresh the page.
Categorization of errors is tricky as we need to compromise between:
Providing as little information as possible, to reduce likelihood of execution forks, e.g. no source code
Providing as much information as possible for the errors to be useful.
Usefulness of error messages depends on the use-case / user persona:
For users of an application it might be sufficient to see in a block explorer that their transaction failed. A detailed error message is not necessary or might be incomprehensible
For a developer of an application it might be necessary to see as much details about a failed transaction to help them debug and fix the problem.
The process of categorization will therefore require lots of feedback from the broader community.
There are of course some details to be worked out, but overall the hope is that this approach can cater to both needs (inclusion of errors in execution results, useful errors for development/debugging)
Issue to be solved
On the Flow protocol side, ANs would like ENs to include errors into execution results, so they can serve requests without additional effort (e.g. re-execution of transaction(s)).
Currently, Cadence produces fine-grained errors, which are very detailed. Changes to the Cadence implementation commonly change errors (e.g. renaming of error type, change in error details, change of error message).
The nature of detailed/fine-grained and such changes increase the likelihood of execution forks, as an EN may produce a semantically equivalent error (e.g. type-checking of a contract failed), but the specific details of the error might be slightly different.
Suggested Solution
Tasks
Categorization of errors is tricky as we need to compromise between:
Usefulness of error messages depends on the use-case / user persona:
The process of categorization will therefore require lots of feedback from the broader community.
cc @peterargue
The text was updated successfully, but these errors were encountered: