fix: close HTTP response bodies in authentication methods

[radulucut]

No description provided.

[coderabbitai]

Walkthrough

This pull request modifies api/auth.go to add defer statements for closing HTTP response bodies across multiple client methods. Specifically, defer resp.Body.Close() is appended after HTTP requests in the exchange, refreshToken, introspection, and RevokeToken methods. These changes do not alter control flow, error handling, or the signatures of any exported functions. The modification affects the go.mod manifest file.

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	No pull request description was provided, which makes it impossible to assess whether descriptive content is related to the changeset.	Add a brief description explaining why closing response bodies is important and which methods are affected.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately and concisely describes the main change: closing HTTP response bodies in authentication methods to prevent resource leaks.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 97a12b8 and 099ad03.

📒 Files selected for processing (1)

• api/auth.go (4 hunks)

🧰 Additional context used

🔍 Remote MCP

The DeepWiki source is not available for this repository. Let me search for general information about Go HTTP response body handling best practices and resource leak prevention to provide relevant context for this PR review.## Summary of Relevant Context for PR Review

Go HTTP Response Body Handling Best Practices

The PR adds defer resp.Body.Close() statements to HTTP client methods in the authentication layer. This change aligns with established Go best practices:

Resource Management:
The Go HTTP documentation explicitly states that "the caller must close the response body when finished with it", and using the defer method to close the response body ensures closure even in case of runtime errors during reading and parsing.

Connection Reuse:
The default HTTP client's Transport may not reuse HTTP/1.x "keep-alive" TCP connections if the Body is not read to completion and closed. This can lead to connection pool exhaustion and resource leaks if bodies are left unclosed.

Practical Impact:
If the Body inside a response is not closed and read to EOF, the client may not re-use a persistent TCP connection; your program will create new connections until the limit for open descriptors is reached, after which no new requests can be sent until the underlying OS frees resources.

Important Implementation Consideration:
A critical pattern to verify: The correct approach is to check for errors after the HTTP call, then defer the close statement, because if a redirection failure occurs, there could be both an error and a non-nil Body that would otherwise leak.

Review Recommendation

When reviewing this PR, confirm that:

1. All HTTP client methods that were modified follow the error-check-first pattern before deferring resp.Body.Close()
2. The changes apply to all affected methods (exchange, refreshToken, introspection, RevokeToken)
3. No existing error handling logic is disrupted by the addition of the defer statements

[::web_search::]

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: windows-latest Go 1.24 Tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[MartinKolarik]

Check the tests please.

[radulucut]

I am not sure what the issue is here. It seems to be a false positive.