-
Notifications
You must be signed in to change notification settings - Fork 562
Conversation
Codecov Report
@@ Coverage Diff @@
## main #272 +/- ##
==========================================
- Coverage 47.46% 46.18% -1.28%
==========================================
Files 46 46
Lines 3160 3267 +107
==========================================
+ Hits 1500 1509 +9
- Misses 1585 1683 +98
Partials 75 75
|
Let's split the binary search logic from the changes in the response. Also if you could add a test suite for the binary search because it's quite critical in the state transition logic |
still , default gas is not working run modifying contract function without "Gas" options. error is different
|
Msg Gas 401130 intrinsicGas 77768 |
|
In my test case, with this PR, the gas used is identical to the estimated one. |
yes, strange
|
in ApplyMessage, that line fails |
When sending tx or doing estimate gas? |
without any gas option , not working |
server side log
|
I think you are using a different version, judging by the line numbers in stack trace. |
i put a lot of logs, to this pr when give gasLimit option, always successful, if gasLimit is enough. no issue. i'll include it to integration test. i'll fetch --all, and check again |
confirmed working good |
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.
lgtm
9488375
to
a16848e
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.
Looks definitely better, see the comment about recursion. There are some conflicts that need to be resolved
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.
overall lgtm
Closes #268 - Also refactor ApplyMessage to be more reuseable move binary search to rpc api side to have a clean context each try remove EstimateGas grpc api
5fc189e
to
e003b32
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.
great stuff
return nil, status.Error(codes.InvalidArgument, err.Error()) | ||
} | ||
|
||
// Binary search the gas requirement, as it may be higher than the amount used |
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.
it's interesting that the binary search on geth is used by the public api side meaning it is done by the client of this grpc server.
At the moment the only relevant issue I've found is ethereum/go-ethereum#21769
I think we should do the binary search on the public API (grpc client side) for sake of matching what they do in Geth
one rpc call emites several grpc query logs.
But this is a reasonable pattern right? I think we can adjust the logs to make it more clear that these are part of the same process... effectively it is slow and painful to estimate gas so logging completions per call is not necessarily bad
@fedekunze also any thoughts on making these RPC server files grpc_query.go
files grpc_server.go
- you might have more context behind the naming but I think it's less obvious.
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.
One thing that's less clean when doing binary search in rpc api side(or grpc client side) is checking the error type for the core.ErrIntrinsicGas
error, in grpc server side, you can inspect the error type directly, in grpc client side, you have to find a sub string in the error message which is not as accurate.
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.
This has to do with not being able to use error.Is
right? Are you sure that's the case? doCall
for example will run through a contract call and expose these error types through vmError
in Geth, we can do this as well?
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.
This has to do with not being able to use
error.Is
right? Are you sure that's the case?doCall
for example will run through a contract call and expose these error types throughvmError
in Geth, we can do this as well?
Do you mean MsgEthereumTxResponse.VmError
? that is serialized version of these errors, when these errors are not further wrapped, you can at least compare the error string as a whole. But if the error is wrapped with stacktrace and grpc status, the best you can do in the grpc client side is strings.Contains
.
@@ -393,3 +400,100 @@ func (k Keeper) EthCall(c context.Context, req *types.EthCallRequest) (*types.Ms | |||
|
|||
return res, nil | |||
} | |||
|
|||
// EstimateGas implements eth_estimateGas rpc api. | |||
func (k Keeper) EstimateGas(c context.Context, req *types.EthCallRequest) (*types.EstimateGasResponse, error) { |
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 you add tests for this on a follow-up 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.
I tried to do it, but there's so many context prepare things to do in unit test environment, I'm not sure how to do it.
- With the default
KeeperTestSuite
,GetCoinbaseAddress
will raise an error - We need to allocate some funds in genesis.
Closes #268
part of it is extracted into #276.
Description
For contributor use:
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerFor admin use:
WIP
,R4R
,docs
, etc)