targetBurstCapacity does not behave correctly when there is more than one activator pod

Expected Behavior

See this post for background where high-availability.replicas was set to 2.

When targetBurstCapacity is set to '-1' the activator should hold on to requests until a pod becomes available to process it. This means that if only 1 pod is available (with containerConcurrency: 1) and 2 long running requests are made, the first request should be processed by the first pod, and a second pod should be scaled to service the second request.

Actual Behavior

When 2 long running requests are made, both requests seem to be sent to the first pod. A second pod is created, but never used.

When high-availability.replicas was reduced to 1 so that only 1 activator was present, expected behavior was observed and targetBurstCapaciry seems to work correctly.

Steps to Reproduce the Problem

1. A cluster with 2 activator pods and 1 running worker pod
2. Set targetBurstCapacity: '-1' , containerConcurrency: 1 and minScale: 1
3. Send 2 long running requests (web socket connections in this case)
4. Observe both requests are sent to the same worker, newly scaled pods are not used

Additional Info

Running on OCP
Serving version v0.19.0
Kourier gateway

Start by reproducing the behavior with two activator pods, one worker pod, targetBurstCapacity -1, containerConcurrency 1, and two long-running requests. Trace the activator request-routing and scaling behavior, then verify that the requests are distributed across available workers and that newly scaled pods receive work.