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

[EVM] Handle EVM errors #5216

Merged
merged 13 commits into from
Jan 12, 2024
Merged

[EVM] Handle EVM errors #5216

merged 13 commits into from
Jan 12, 2024

Conversation

devbugging
Copy link
Contributor

@devbugging devbugging commented Jan 9, 2024

Closes: #5149

This PR adds a type of EVMError that satisfies the UserError which is handled by Cadence at the same time embedding the CodedError.

The error output now looks like:

[Error Code: 1300] error caused by: 1 error occurred:
	* [Error Code: 1101] cadence runtime error: Execution failed:
 --> ff292f561c9cba05ef08abd74bc90cbaca1c217f737312d00b8fcf7ccafc405d:8:12
  |
8 | 				destroy acc.withdraw(balance: bal);
  | 				        ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: [Error Code: 1300] evm runtime error: insufficient total supply
  --> 8c5303eaa26202d6.EVM:89:12
   |
89 |             let vault <- InternalEVM.withdraw(
90 |                 from: self.addressBytes,
91 |                 amount: balance.flow
92 |             ) as! @FlowToken.Vault
   |             ^^^^^^^^^^^^^^^^^^^^^^


Copy link
Contributor

@janezpodhostnik janezpodhostnik left a comment

Choose a reason for hiding this comment

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

Nice!

Comment on lines +225 to +226

func (e EVMError) IsUserError() {}
Copy link
Contributor

Choose a reason for hiding this comment

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

So is this the missing part ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically, this makes it conform to the type of Cadence User Error which doesn't contain the stack and is handled gracefully.
Now we could maybe even go further and adding an EVM error type in Cadence handling which I think could be even nicer way to go, but this solves it for now and we can add it to the todo if you think so?

@ramtinms
Copy link
Contributor

ramtinms commented Jan 9, 2024

I think we need 3 tests

  • one for when a fatal error is happening down there
  • one for when a stateDB error is happening (non-fatal)
  • one for when a evm tx is failed

@devbugging
Copy link
Contributor Author

I think we need 3 tests

  • one for when a fatal error is happening down there
  • one for when a stateDB error is happening (non-fatal)
  • one for when a evm tx is failed

Ok, will add these tests as well.

@devbugging
Copy link
Contributor Author

devbugging commented Jan 10, 2024

happening down there

In the basement where the EVM is 😆

@codecov-commenter
Copy link

codecov-commenter commented Jan 10, 2024

Codecov Report

Attention: 10 lines in your changes are missing coverage. Please review.

Comparison is base (c1fdaa8) 56.55% compared to head (e2c455f) 56.35%.
Report is 69 commits behind head on master.

Files Patch % Lines
fvm/errors/errors.go 0.00% 10 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #5216      +/-   ##
==========================================
- Coverage   56.55%   56.35%   -0.21%     
==========================================
  Files         988      994       +6     
  Lines       94422    94810     +388     
==========================================
+ Hits        53403    53427      +24     
- Misses      37054    37408     +354     
- Partials     3965     3975      +10     
Flag Coverage Δ
unittests 56.35% <0.00%> (-0.21%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

fvm/fvm_test.go Outdated
Comment on lines 3094 to 3113
// evmErrorSnapshot will return an error once it gets to reading the EVM
// registers for address allocator, that way we can at that point return a provided
// error, that error type is then checked against the provider checker.
type evmErrorSnapshot struct {
snapshotTree snapshot.SnapshotTree
err error
errChecker func(error) bool
}

func (s evmErrorSnapshot) Get(
id flow.RegisterID,
) (
flow.RegisterValue,
error,
) {
if id.Key == "AddressAllocator" {
return nil, s.err
}

return s.snapshotTree.Get(id)
Copy link
Contributor

Choose a reason for hiding this comment

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

hmm, I guess there should be a MockedSnapshot somewhere either created by mockery or implemented with func methods, If it doesn't exist we should create it in my view, that way we have more clear tests that are not dependent on a logic outside of the test.

Copy link
Contributor

Choose a reason for hiding this comment

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

@janezpodhostnik do you know if we have one ?

Copy link
Contributor Author

@devbugging devbugging Jan 11, 2024

Choose a reason for hiding this comment

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

I agree on the approach. I've checked before for existing ones but only found, one in accounts that is just an implementation for tests here

type errorOnAddressSnapshotWrapper struct {
and one in util
type PayloadSnapshot struct {

So will generate one with mockery for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ramtinms fixed

Copy link
Member

@turbolent turbolent left a comment

Choose a reason for hiding this comment

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

Nice!

@devbugging devbugging added this pull request to the merge queue Jan 11, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jan 11, 2024
@devbugging devbugging added this pull request to the merge queue Jan 12, 2024
Merged via the queue into master with commit 6c6a7f6 Jan 12, 2024
51 checks passed
@devbugging devbugging deleted the gregor/evm/runtime-error-handling branch January 12, 2024 18:04
Sign up for free to 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.

[Flow EVM] - evm non-fatal runtime errors are not handled properly by FVM
5 participants