We currently get a mev relays health status in the test command. This is certainly more accurate than pinging the URL, which we had been doing originally to infer request duration, but is still not the real hot path when a relay is in use.
๐ ๏ธ Proposed solution
If we were to also give the test mev command an optional CL REST API (--beacon-node-endpoints), it would be able to figure out the correct details to ask a relay for a payload for the real time next slot. This would be more representative than hitting the health endpoint. It could probably be implemented as a second test.
๐งช Tests
[ ] Tested by new automated unit/integration/smoke tests
[ ] Manually tested on core team/canary/test clusters
๐ฏ Problem to be solved
We currently get a mev relays health status in the test command. This is certainly more accurate than pinging the URL, which we had been doing originally to infer request duration, but is still not the real hot path when a relay is in use.
๐ ๏ธ Proposed solution
If we were to also give the
test mev
command an optional CL REST API (--beacon-node-endpoints), it would be able to figure out the correct details to ask a relay for a payload for the real time next slot. This would be more representative than hitting the health endpoint. It could probably be implemented as a second test.๐งช Tests