HiveClients.DefaultNodes in dotnet/EcencyApi/Infrastructure/HiveRpcClient.cs still lists https://hive-api.3speak.tv. The host resolves but never completes a TCP connect, so every attempt against it costs the full per-node timeout and answers nothing.
Reproduce from anywhere:
curl -s -m 8 -o /dev/null \
-w 'code=%{http_code} connect=%{time_connect}s total=%{time_total}s\n' \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"condenser_api.get_dynamic_global_properties","params":[]}' \
https://hive-api.3speak.tvconnect stays at 0 and the request ends at the -m ceiling with code=000.
The same file already documents dropping hive-api.arcange.eu for exactly this failure mode. A node that answers nothing is not simply a slow node: the health tracker learns latency from answers, so it has none to learn from. NodeHealthTracker does park it after three consecutive hard failures, but the park lapses and it is probed again, and while it is unparked it sits in config order where any cold or freshly reset latency profile reaches it.
What to change
- Remove the entry from
HiveClients.DefaultNodes and extend the comment above the list the way the arcange note reads, so the reason survives the next person who wonders why the pool is short.
DefaultPool_DoesNotCarryTheUnreachableNode in EcencyApi.Tests/HiveRpcFailoverTests.cs already asserts the arcange absence together with a pool-size floor; extend that fact rather than adding a second one.- Re-check the node at the time of the change rather than trusting this issue. If it is answering again, leave it in and close this.
HiveClients.DefaultNodesindotnet/EcencyApi/Infrastructure/HiveRpcClient.csstill listshttps://hive-api.3speak.tv. The host resolves but never completes a TCP connect, so every attempt against it costs the full per-node timeout and answers nothing.Reproduce from anywhere:
connectstays at 0 and the request ends at the-mceiling withcode=000.The same file already documents dropping
hive-api.arcange.eufor exactly this failure mode. A node that answers nothing is not simply a slow node: the health tracker learns latency from answers, so it has none to learn from.NodeHealthTrackerdoes park it after three consecutive hard failures, but the park lapses and it is probed again, and while it is unparked it sits in config order where any cold or freshly reset latency profile reaches it.What to change
HiveClients.DefaultNodesand extend the comment above the list the way the arcange note reads, so the reason survives the next person who wonders why the pool is short.DefaultPool_DoesNotCarryTheUnreachableNodeinEcencyApi.Tests/HiveRpcFailoverTests.csalready asserts the arcange absence together with a pool-size floor; extend that fact rather than adding a second one.