BalancedPool deteriorates to a single point of failure after outages

[justSchilling]

Bug Description

After the configured backends for a balanced pool have failed for a bit, they all end up at equal low-end weights. If a balanced pool is configured with 2 hosts and 1 connection each, at this point the current implementation will always pick the same backend for further requests instead of switching between the 2 options. This causes a disruption to expand unnecessarily until whichever Backend ended up on top of the heap becomes healthy again.

The mechanism seems to work fine when more 2 hosts are added, recovering soon after one host is available.

Reproducible By

Set up a balanced pool with 2 hosts. Spam some requests while the hosts are down. Observe requests being sent.

Expected Behavior

Hosts of equal weight have equal chances of selection, leading to successful recovery when 1 of 2 hosts are available, regardless of ordering.

Logs & Screenshots

Let me know if a particular log would help the investigation. I'm not familiar with this projects best practices.

Environment

Undici 7.2.3 in project where I first observed the bug / current main branch for reproduction on private pc
Node 22, MacOS 26.3, Fedora 43

[mcollina]

If you could create a github repo to reproduce this condition, that would be really helpful.

[justSchilling]

https://github.com/justSchilling/undici-playgound/blob/main/balancedpool-request-distribution.js

i'll see if i understand your test setups after work to make this less clunky

observed output on my end:
phase 1 all fine
=== phase1_all_up (12 requests) ===

1. OK:A:3101:200
2. OK:A:3101:200
3. OK:A:3101:200
4. OK:A:3101:200...

phase 2 tank everything to weight 1

phase 3 one host up but no connection tried to it
=== phase3_A_up (24 requests) ===
event: connectionError from B:3102 (ECONNREFUSED)

1. ERR:B:3102:ECONNREFUSED
   event: connectionError from B:3102 (ECONNREFUSED)
2. ERR:B:3102:ECONNREFUSED
   event: connectionError from B:3102 (ECONNREFUSED)
3. ERR:B:3102:ECONNREFUSED...

phase 4 both hosts back up but only one gets requests
=== phase4_all_up_again (12 requests) ===

1. OK:B:3102:200
2. OK:B:3102:200
3. OK:B:3102:200...