the root cause is that when `inMemoryExecution` lambda gets created in
the `eth/backend.go`, it captures the reference of
`backend.notifications`, and so the execution of side-forks actually
adds notifications to there, and it all gets sent out to tx pool (and
RPC daemon) at the end of the stage loop (regardless of whether there
was forkchoice update or not)
so we can create a separate notification, but then somehow flush it to
the "main" nofitications when the in-memory exec state is flushed
Co-authored-by: Alexey Sharp <alexeysharp@Alexeys-iMac.local>
Co-authored-by: Alex Sharp <alexsharp@Alexs-MacBook-Pro.local>
* avoid constantly triggering stageloop when using Engine API
* fix lint + test
* fixed comments
* ops
* little fixes here and there
Co-authored-by: giuliorebuffo <giuliorebuffo@system76-pc.localdomain>
Reduce the likelihood of a deadlock caused by goroutine starvation on CI.
The CI macOS runners have 3 cores.
When running other tests in parallel having too few available cores could cause a deadlock.
Test with:
GOMAXPROCS=2 go test ./cmd/rpcdaemon/commands/eth_subscribe_test.go -test.count 100 --timeout 10s
Expected: the command finishes within 3 sec
Before the fix: it timeouts (without a timeout - hangs forever)
* Stricter transition check
* EthBackendServer.numberSent was unused
* Take account of PoS blocks in TopSeenHeight
* Report Valid ExecutionStatus only after all stages, not straight in headers
* Print TTD on startup
* No need to check parent.Hash() again
* core: change baseFee into baseFeePerGas in genesis json
* fix typo
Co-authored-by: Martin Holst Swende <martin@swende.se>
