* Adopt asyncraises guarantees to most of the REST API handlers.
Bump presto.
* Fix copyright year.
---------
Co-authored-by: Etan Kissling <etan@status.im>
- Feature flag for raises support
- HTTP server middleware implementation
- Fix examples documentation
- check leaks after every test
- deprecate `callback=`, UDP fixes
- Improve parseList and parseInlineTable strictness
- v0.2.10
- Switch to llvm-mingw for faster Windows CI
- Add configureTomlDeserialization to README.md
- Put array/inline table nonstandard behavior behind flag
- Unify parseList and parseArray implementation
- v0.2.12
- Fix a bunch of compiler hints and warnings in uTP and discv5
- Fix missing std/times import for the metrics 0.0.1 case
- Fix for uTP issues with latest chronos
- Clean-up, correct and clarify utp_protocol tests
- better async timeout wait
- Adjust test names and comments for `blobGasUsed` field
- Add data over multiple sockets uTP test
- Add uTP over discv5 test and small uTP performance improvements
#5773 removed catching up on validator duties after lag. The `curSlot`
variable that was used originally to track catch-up progress no longer
has a use and is also no longer properly updated. Remove it.
If the initial state replays cover the finalized head, import matching
`LightClientBootstrap` into database.
This also addresses this error when light client requests bootstrap from
the genesis slot on networks that launch with Altair enabled.
```
{"lvl":"DBG","ts":"2023-10-04 11:17:49.665+00:00","msg":"LC bootstrap unavailable: Sync committee branch not cached","topics":"chaindag_lc","slot":0}
```
Avoid marking blocks invalid when corresponding `blobSidecarsByRange`
returns an incomplete / incorrect response while syncing. The block
itself may still be valid in that scenario.
There are two conditions leading to `duplicate contribution` log.
Align the logs with the ones used for attestation aggregates,
so that the two conditions can be separated when reading logs.
The `blob_gas_used` field was not properly populated when constructing
Deneb light client data. This is due to #5026 not applying the change to
the entire codebase when the new field got introduced, and due to #5350
not catching that oversight in other modules. Also reviewed codebase and
discovered that `shortLog` for Deneb execution payloads has same bug.
To simplify supporting "am I ready for the fork" requests, add a simple
marker to the default status bar that indicates readiness by displaying
the fork's corresponding mascot. This is the same one that is also
displayed during the actual fork transition, so does not introduce
new dependencies. It also only shows in default status bar, not in logs.