You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RPC Resolver: If all are unhealthy, return the default RPC (#77)
# What
Improved RPC fallback selection logic to choose default-priority (0) entries when no healthy RPCs are available.
New (not-yet polled) RPCs are now initialized as `Unhealthy` instead of Healthy with a fake latency based on order of definition.
This change removes reliance on order of defining RPCs in rpc-config.yaml
followup to #73
# Why
Some of our services (prov bootstrap) request RPCs before healthcheck poller has had a chance to run. We thus have no idea which RPC from the list to return and should prefer the one with the highest likelihood of being available.
Previously, new entries that have not yet been polled were initialized as Healthy, which according to the new selection method led to the replica IP being selected (highest priority) before it could be proven to be Unhealthy by the poller, which broke prov bootstrap.
The previous selection algorithm just selected by order of definition in this case (first RPC defined in the file) which is brittle and darkmagic-y as well.
This change ensures we use a more reliable default-priority remote RPC anytime we don't know which RPC is actually available, which is typically a public or private remote RPC to that chain and can be more safely assumed to be available.
This default (priority-0) RPC is now mandatory for every chain that might be used in such way and prio 0 now has a special meaning.
# Background
During prov bootstrap, the healthcheck poller requests a yellowstone RPC immediately on boot without waiting for a healthcheck cycle. Previously, a replica URL was selected due to high prio because not-yet polled RPCs were initialized as Healthy, which made prov boot fail.
0 commit comments