api: fix response body leak when rawRequestWithContext returns error

[raman1236]

Description

Fix a resource leak in the Vault API client where HTTP response bodies are not closed when rawRequestWithContext returns both a non-nil response and a non-nil error.

Problem

Several API client methods check if err == nil before closing the response body:

resp, err := c.c.rawRequestWithContext(ctx, r)
if err == nil {
    defer resp.Body.Close()
}
return err

However, rawRequestWithContext can return a non-nil response along with a non-nil error (e.g., for non-2xx HTTP status codes, redirect errors, etc.). When this happens, the response body is never closed, causing a resource leak that can gradually exhaust system resources.

Fix

Changed the check from if err == nil to if resp != nil:

resp, err := c.c.rawRequestWithContext(ctx, r)
if resp != nil {
    defer resp.Body.Close()
}
return err

This matches the pattern already used within rawRequestWithContext itself (client.go lines 1522-1524) and ensures the response body is always properly closed regardless of whether an error is returned.

Affected Methods (11 files, 23 instances)

• sys_audit.go: DisableAuditWithContext
• sys_auth.go: DisableAuthWithContext
• sys_config_cors.go: ConfigureCORSWithContext, DisableCORSWithContext
• sys_generate_root.go: generateRootCancelCommonWithContext
• sys_leases.go: RevokeWithContext, RevokePrefixWithContext, RevokeForceWithContext, RevokeWithOptionsWithContext
• sys_mounts.go: UnmountWithContext, TuneMountAllowNilWithContext
• sys_plugins.go: RegisterPluginWithContext, DeregisterPluginWithContext
• sys_plugins_runtimes.go: RegisterPluginRuntime, DeregisterPluginRuntime
• sys_policy.go: DeletePolicyWithContext
• sys_rekey.go: RekeyCancelWithContextWithNonce, RekeyRecoveryKeyCancelWithContextWithNonce, RekeyVerificationCancelWithContext, RekeyRecoveryKeyVerificationCancelWithContext, RekeyDeleteBackupWithContext, RekeyDeleteRecoveryBackupWithContext
• sys_rotate.go: RotateWithContext

[vercel]

@ramanvasi is attempting to deploy a commit to the HashiCorp Team on Vercel.

A member of the Team first needs to authorize it.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

1 out of 2 committers have signed the CLA.

• ramanvasi
• raman1236

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[heatherezell]

@raman1236 please ensure that any commits made with your email, etc, all line up to the same github account information, otherwise the CLA bot gets confused

[raman1236]

@heatherezell Thanks for the heads up! I've signed the CLA with my raman1236 GitHub account — the CLA check is now passing (shows "Contributor License Agreement is signed"). The two committer identities were from different local git configs, but both map to the same person. Let me know if there's anything else needed!

[raman1236]

Friendly ping — this PR has been open for a few weeks now. The CLA is signed, tests pass, and the fix is a straightforward one-liner that prevents response body leaks in the API client. Would love a review when you get a chance. Thanks!