Closed agostbiro closed 4 months ago
Latest commit: cae0e7b08d2399aa0c0311bacb61c7c4185f97e6
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
The JSON-RPC response struct in
edr_eth
contains the response in thedata
field which is flattened for serialization to allow handling theresult
/error
field as an enum:Turns out this doesn't play well with the
arbitrary_precision
feature ofserde_json
which causes the response frometh_feeHistory
fail to parse. The reason onlyeth_feeHistory
is failing, because this is the only RPC response with a number in it, all other methods supported by the client return numbers as hex strings.The EDR crates don't need the
arbitrary_precision
feature ofserde_json
, but it's needed by theparseJson
Foundry cheatcode. The reason it's causing problems inedr_eth
is feature unification which kicks in when both the EDR and Foundry crates are included inedr_napi
.To fix the problem I added custom deserialization logic for the numerical field of the
eth_feeHistory
response. Parsing the numbers first intoserde_json::Number
and then into the desired number type makesflatten
work witharbitrary_precision
.I also made all EDR crates refer to the workspace version of
serde
andserde_json
. This was the case before as well (as evidenced by the lack ofCargo.lock
change), but this way it's clearer to the reader.I have taken the approach of not having per-crate feature definitions for
serde
andserde_json
, but having all the required ones in the workspace'sCargo.toml
. This way there are no surprises when code under test behave one way in a crate, but behaves differently when used as a dependency in another trait.