Description
When the configured Zenarmor connection cap is full, the limited listener accepts each additional TCP connection and closes it immediately, then continues without a rejection counter or bounded diagnostic. A slow-connection flood can make sender writes fail or retry while every receiver metric remains healthy, hiding that the configured cap is the cause.
Acceptance Criteria
- #1 A listener-level regression holds the configured connection slots, attempts one more connection and observes explicit cap-rejection accounting
- #2 The rejection signal is bounded and identifies the connection-cap reason without adding an unbounded label
- #3 Normal accepted-connection slot release and shutdown behavior remain unchanged
Definition of Done
- #1 just check
- #2 just gen (if any generated artifact changed) and the diff committed
Implementation Plan
Add a failing limited-listener regression for an over-cap connection, then expose a bounded rejection counter through the existing Zenarmor receiver stats and add a rate-limited diagnostic only if the counter is insufficient for the operator path.
Final Summary
Fixed by a4e0e20a. Zenarmor socket-cap refusals now increment the existing bounded rejected-record counter with reason conn_limit, with no peer label. The listener-level regression failed before the fix and passed after it, including slot reuse and shutdown. Integrated just check passed. CodeRabbit completed one pass with zero findings.