-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Update SimulatedBackendClient CallContext #11164
Update SimulatedBackendClient CallContext #11164
Conversation
I see that you haven't updated any README files. Would it make sense to do so? |
return common.HexToAddress(v), nil | ||
case *big.Int: | ||
return common.BigToAddress(v), nil |
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.
Are there variants that return errors instead of failing silently?
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.
So far, the way it is used in tests, no. And it shouldn't fail silently. Everywhere this function is used will panic if it can't handle the value type. It's not ideal, but the way this is mainly used is in unit testing. So if it fails, the unit tests will fail.
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.
The Hex/BigToAddress
funcs silently accept invalid values that could be difficult to debug from an indirect failure. Why don't we use IsHexAddress
?
And could check for big.Int > 0
and b.Bytes() <=20
?
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.
Ahh. Ok. I'll give that a Go...
ef51143
to
458c50e
Compare
default: | ||
// panic("not implemented") |
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.
commented code
The function `CallContext` has different supported contract function calls than `BatchCallContext` even though the latter is simply a batch version of the former. This commit makes the two functions match both in the supported calls, but also in the validation and execution of those calls.
Use suggestion on default address returned on error. Co-authored-by: Jordan Krage <[email protected]>
…simulated backend client
2b2cf36
to
d38e967
Compare
The function
CallContext
has different supported contract function calls thanBatchCallContext
even though the latter is simply a batch version of the former.This commit makes the two functions match both in the supported calls, but also in the validation and execution of those calls.