BuilderApiClient.clients is keyed by builder url and populated by getOrCreateClient, which runs on every preference submission and bid request. Nothing ever removes an entry.
checkStatus() added in #9947 iterates the whole map before each proposal, so a builder dropped from the validator client config keeps being pinged until the beacon node restarts, and logs Builder status check failed every proposal if it is offline.
The bid fan-out is unaffected, it only requests bids from the entries the validator client sends with produceBlockV4.
Bounded in practice by how many distinct builder urls an operator runs and cleared by a restart, so this is only about avoiding pointless requests and a misleading warn. Tracking last use per client and dropping entries not seen for a few epochs would be enough.
BuilderApiClient.clientsis keyed by builder url and populated bygetOrCreateClient, which runs on every preference submission and bid request. Nothing ever removes an entry.checkStatus()added in #9947 iterates the whole map before each proposal, so a builder dropped from the validator client config keeps being pinged until the beacon node restarts, and logsBuilder status check failedevery proposal if it is offline.The bid fan-out is unaffected, it only requests bids from the entries the validator client sends with
produceBlockV4.Bounded in practice by how many distinct builder urls an operator runs and cleared by a restart, so this is only about avoiding pointless requests and a misleading warn. Tracking last use per client and dropping entries not seen for a few epochs would be enough.