-
Notifications
You must be signed in to change notification settings - Fork 354
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
Out of gas handling #331
Out of gas handling #331
Conversation
c6f578a
to
44ca77e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just went over my diff again and added a few notes. Most of these are for myself but one is for the other reviewers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice work, great points.
I guess it will be hard to update. Maybe we can split this PR a little bit into smaller chunks to get them in?
Thanks! :D It took a lot of time to figure out a lot of the subtleties here, as you've seen so far.
My plan for Sunday is to churn through all the conflicts i'll get after running |
Okay, let's try to get this in first. After it is merged there are a few action items (not necessarily for you) good to get done on Monday (for 0.8.0):
|
Cool 👍 |
@reuvenpo no worries. Amazing work has been done already and my focus is to reduce the diff, allowing us to progress in parallel from there. |
|
|
Done :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work on the major overhaul. There seem to be multiple different concerns in this PR, but good stuff in general. Added some comments on structure.
}, | ||
} | ||
|
||
impl FfiError { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for? I generally don't like the idea of modifying errors.
Maybe just a simpler constructor ffi_error(message: S) -> FfiError
that returns an FfiError::Other
variant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, this isn't a constructor. you can see how i use it, it's kind of like the context
method from snafu::ResultExt
. it basically says "If the value is a specific variant of the type, please give it this additional data". In this case i say that if it can, please add this message with context information. It's used to give a specific error message when go has an unexpected error (not panic) and we have something useful to say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be implemented as a constructor, i.e. keep the error immutable? Or do we get the error from somewhere and need to add the information later on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhh, i suppose it could be? Let me play around with it. If you look at the places this is used, we first convert a GoResult
to Result<(), FfiError>
, and then if we got Other
we add an error message with this method. I can wrap that up into an associated function on GoResult
, perhaps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not too important in my opinion. Wrote it down here: #336
start: Option<&[u8]>, | ||
end: Option<&[u8]>, | ||
order: Order, | ||
) -> FfiResult<Box<dyn Iterator<Item = FfiResult<KV>> + 'a>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so copying all this code is to give us the proper Result/Error type for the iterator (and other ops). It seems necessary to match the different function signatures, but it is also missing any code that would let use test the error cases. I would propose replacing this with the following:
- A wrapper that takes
cosmwasm_std::Storage
and converts tocosmwasm_vm::Storage
(different return types). This would convert anyStdError
toFfiError::Other
by stringifying it. It lets us easily reuse code for the success-case. - An implementation that always returns an error, where you can set an
FfiError
to in the struct, and all calls will return this error (cloned). I think it is critical to test this error handling - which is a large part of the refactor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another case for this is the fact that staking contract is failing.
My integration test customizes the Querier (staking module), but that uses the cosmwasm_std::Extern. Having no (test-safe) translation to cosmwasm_vm::Extern makes life hard here (and a whole lot more code copying if I want to support this). I think some transforms allow the two to diverge, but let us easily re-use test helpers. Such transforms can be in the testing
/mock
modules to signify they should only be used for test code (like MockStorage
, MockQuerier
, etc)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uhm, i just fixed the staking contract integration tests by changing an import and tweaking a function signature to reflect a change that was made after i forked. i just pushed it but everything's passing on my machine, so it should pass here in a few minutes as well.
As for the suggestion in your first comment on this thread, that sounds good, but i don't think there's a strong need to do this right now. there were already tests that checked for errors in a lot of the code i touched, and i had to modify those tests to reflect my changes. Most of what i did is already backed by tests. The only thing that i feel that i should write a test for, is the case where things run out of gas, but i don't want to do it before i've completed the full error flow for that scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, these were ideas for future enhancements rather than in this pr.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Solid and strictly better than current master. Ready to merge from my point of view
This PR aims to fix CosmWasm/wasmvm#29 .
It adds all the support required in the
cosmwasm-vm
crate (which is a lot)