LB lagging health check RPC endpoint #63
Conversation
finiteops
force-pushed
the
bitfinity-lb-endpoint
branch
from
b8165ff to
f046a05
Compare
ufoscout
left a comment
ufoscout
left a comment
There was a problem hiding this comment.
In general, the approach proposed in this PR will not work in many situations. For example, if the node is not able to properly reach the primary URL or if the node's primary URL is out of sync, this will return a wrong result.
crates/rpc/rpc-eth-api/src/core.rs
Outdated
| None => U256::from(3), | ||
| }; | ||
|
|
||
| let network_block = BitfinityEvmRpc::network_block_number(self).await?; |
There was a problem hiding this comment.
Our system manages remote URLs with automatic fallbacks if a URL is not reachable. The way this endpoint is implemented, instead, does not respect it; as a consequence, this function could return a wrong result if the URL is not the primary one that the node is currently using
There was a problem hiding this comment.
I guess there will be no issues unless it returns response from the node that it currently syncs with
finiteops
force-pushed
the
bitfinity-lb-endpoint
branch
from
036410e to
efc6162
Compare
If primary URL is not available (none of them). It will return success (acceptable lag) just to do not break LB. |
|
|
||
| // Need time to generate extra blocks at `eth_server` | ||
| // Assuming it ticks 100ms for the next block | ||
| tokio::time::sleep(std::time::Duration::from_millis(1500)).await; |
There was a problem hiding this comment.
We usually avoid direct sleeping when possible. Instead of sleeping, check your condition in a finite-loop with minimal sleep of a few ms between loops.
No description provided.