* Fix contract_dsl event response parser
* Fix pending subscription event handler
* Use useDefaultSerializationIn for EventData
Surprisingly the pending event bug not detected when using ganache. It only manifest after migrated to hardhat. Also not detected on linux and windows CI. Only on macos amd64 CI, and sometimes on macos arm64 CI. Probably related to async timing trigger pending event?. But it's a genuine bug, dated back far before migration from stdlib/json to json-serialization.
- https://github.com/ethereum/execution-apis/releases/tag/v1.0.0-beta.4
This was already partially applied, the following commits were missing:
- update the doc of eth_getBalance to put block as required parameters
- schemas/filter: fixup some bugs in null filter topics and address
- tests: regenerate tests with new rpctestgen chain
- tests: add forkenv.json for hive
- tests: add headfcu.json
- tests: add comments in tests
- Specify Client Versions on Engine API
- Add eth_blobBaseFee; add blobs to eth_feeHistory
- Added engine_getPayloadV4 and engine_newPayloadV4 for Prague
- Update receipt.yaml to title instead of name
- Move EIP-6110 to Prague
- Add EIP-7251 to Prague
- engine: rename for 7002 partial withdrawals and 7685 requests
The `writeValue` added for `BlockNumber` in #136 interferes with other
`uint64` because `BlockNumber` is not `distinct`. Marking it `distinct`
avoids polluting global serialization logic.
The test is already included in previous commit of
test_execution_api fix. I separate the commit to let
users of this library aware of this changes.
This changes is also needed in eth hive test of rpc compat simulator.
* Replace eth_getBlockReceipts return type with Opt[T] instead of Option[T]
reason:
Option[T] failed to compile when using nim v2
it is related to ref object. But also hard to reproduce outside
combination of nim-json-serialization + nim-json-rpc + something
* Add note about nim v2 regression
* Add test case of eth_getBlockReceipts usage
In #108 a regression got introduced, resulting in `fromBlock`, `toBlock`
and `blockHash` no longer being sent when a client calls `eth_getLogs`.
This may break the deposits import process in `nimbus-eth2`, resulting
in messages such as:
```
ERR 2024-02-06 19:52:34.474+01:00 The Eth1 chain is not synced ourDepositsCount=0 targetDepositsCount=403
```
Fixing the regression restores successful import messages:
```
INF 2024-02-06 22:12:14.863+01:00 Eth1 sync progress topics="elmon" blockNumber=1349452 depositsProcessed=3
```
tersec
andri lim
Jacek Sieka
Miran
Hiroki Noda
Yuriy Glukhov
Etan Kissling
Kim De Mey