Avoid redundant _release_connection calls

[rodrigobnogueira]

What do these changes do?

This change removes redundant ClientResponse._release_connection() invocations on successful request paths.

• ClientResponse.release() now calls _release_connection() only when _connection is still present.
• ClientResponse._wait_released() now does the same guard.
• ClientResponse.wait_for_close() no longer calls release() a second time when already released.
• Added regression test test_release_connection_called_once_per_request.
• Added changelog fragment CHANGES/10089.bugfix.rst.

Are there changes in behavior for the user?

Yes, internal behavior changed: a successful request now executes one release-path call per response instead of repeated no-op release calls. Connection reuse/cleanup semantics are preserved.

Is it a substantial burden for the maintainers to support this?

No. The change is small, localized, and covered by regression + existing suite coverage.

Related issue number

Fixes #10089

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.10%. Comparing base (8663d2a) to head (e487283).
⚠️ Report is 4 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12221      +/-   ##
==========================================
- Coverage   99.11%   99.10%   -0.01%     
==========================================
  Files         130      130              
  Lines       45324    45359      +35     
  Branches     2392     2394       +2     
==========================================
+ Hits        44921    44955      +34     
  Misses        271      271              
- Partials      132      133       +1     

Flag	Coverage Δ
CI-GHA	98.96% <100.00%> (-0.01%)	⬇️
OS-Linux	98.71% <100.00%> (+<0.01%)	⬆️
OS-Windows	96.97% <100.00%> (-0.01%)	⬇️
OS-macOS	97.86% <100.00%> (-0.01%)	⬇️
Py-3.10.11	97.41% <100.00%> (+<0.01%)	⬆️
Py-3.10.19	97.89% <100.00%> (+<0.01%)	⬆️
Py-3.11.14	98.09% <100.00%> (+<0.01%)	⬆️
Py-3.11.9	97.61% <100.00%> (+<0.01%)	⬆️
Py-3.12.10	97.70% <100.00%> (+<0.01%)	⬆️
Py-3.12.12	98.18% <100.00%> (+<0.01%)	⬆️
Py-3.13.12	98.43% <100.00%> (-0.01%)	⬇️
Py-3.14.3	98.49% <100.00%> (-0.01%)	⬇️
Py-3.14.3t	97.48% <100.00%> (+<0.01%)	⬆️
Py-pypy3.11.13-7.3.20	97.52% <100.00%> (+<0.01%)	⬆️
VM-macos	97.86% <100.00%> (-0.01%)	⬇️
VM-ubuntu	98.71% <100.00%> (+<0.01%)	⬆️
VM-windows	96.97% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 59 untouched benchmarks

---

_{Comparing rodrigobnogueira:bugfix/10089-release-connection-once (e487283) with master (8663d2a)¹}

Footnotes

1. No successful run was found on master (d0127db) during the generation of this report, so 8663d2a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[Dreamsorcerer]

This check already happens inside _release_connection(). Is it the function call itself that's adding too much overhead? I'll leave @bdraco to review this one.

[rodrigobnogueira]

@Dreamsorcerer , I've opened this one because I thought there was some job in the CI that could make the change relevant.

The statement if self._connection is not None: was already in _release_connection when the issue was opened.

Issue #10089 opened: 2024-12-02. release_connection() itself was introduced in 9c07121 (2023-11-03) with the same internal guard from the start.

def _release_connection(self) -> None:
    if self._connection is not None:
        ...

Unless I'm missing something, I think this PR and the issue can be closed.

[Dreamsorcerer]

Yeah, that's my question to @bdraco. If you see my comment there, I think it may be possible to remove one of these calls entirely, but the other 3 need to remain.