mirror of
https://github.com/ChainSafe/lodestar.git
synced 2026-01-10 08:08:16 -05:00
ac704f28d2
**Motivation** While going through block production logs I noticed in some rare cases we sent header requests pretty delayed into the slot, but not if you look at our logs, it shows that header was sent at ~100ms but mev-boost received it at ~600ms which is a huge discrepancy. When further analysing this I noticed that ~600ms is roughtly the time we finished producing the common block body. This means we can't really trust the logs here as they might be emitted but the actual HTTP request is not sent. Since this issue is pretty rare and most of the time we sent the requests <100ms I think it's race condition and highly depends on I/O timing and what other async/sync load is processed. Another interesting side effect of this is that when these huge delays happen (up to 500ms) I also noticed that builder HTTP requests run into the 1 second timeout even though it looks from mev-boost perspective that response was sent within time. My guess here is that the `fetch` implementation sets the timer and starts it but since sending the actual HTTP requests requires to go through poll phase it might not actually bet sent. Long story short, we need to wait until next evet loop iteration to ensure I/O operations are processed before starting common block body production as it is synchronous and blocking. **Description** Defer call produce common block body `produceCommonBlockBody` to next event loop by running it in `setImmediate` callback. Previous PR https://github.com/ChainSafe/lodestar/pull/7814