The in-flight count needs a precise release event when a caller disconnects. Releasing its slot immediately can undercount work if cancellation has not yet stopped the provider request; retaining it forever can leak capacity after an acknowledged cancellation.
I would distinguish caller completion from upstream attempt termination and exercise both races in the saturation test. A replacement request should acquire capacity only according to the resource actually being protected. That makes max_inflight meaningful during disconnect storms, when frontend request counts and active provider work can diverge sharply.