onflow
Translate fine-grained errors into coarse-grained, standardized errors
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
- [ ] Standardize coarse-grained errors that any version of Cadence may produce
- [ ] Categorize existing errors into these coarse-grained categories of errors and add translation functions (wrap)
- [ ] By default, produce standardized coarse-grained errors. Add an option to produce fine-grained errors instead (avoid translation / wrapping)
- [ ] In assertion utility functions, ensure only standardized errors are generated
- [ ] Define and implement a deterministic encoding of standardized coarse-grained errors (e.g. not JSON)
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.
cc @peterargue
Just to make sure I understand correctly, the idea here is that:
- Cadence will continue to report fine-grained errors
- But they will be converted to more coarse-grained errors, before sending it out to AN/EN
- These coarse-grained errors are not convertible back to fine-grained errors
- But has the option to return the fine-grained error if needed (without the conversion)
Is that understanding correct?
@SupunS Yes, that matches the idea well 👍
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)
