fix: propagate ssl_verify in AsyncHTTPHandler retry paths and BaseLLMAIOHTTPHandler

[Vitaliy-Pikalo]

Problem

Fixes #30778

ssl_verify is silently dropped in two places:

1. AsyncHTTPHandler retry paths — post(), put(), patch(), and delete() all catch httpx.RemoteProtocolError / httpx.ConnectError and recreate the client via self.create_client(), but none passed ssl_verify. This means any retry after a connection error ignores the user's SSL setting.

2. BaseLLMAIOHTTPHandler — __init__ had no ssl_verify parameter, so _get_or_create_transport() called AsyncHTTPHandler._create_aiohttp_transport() without any SSL args.

Fix

http_handler.py

• Store ssl_verify on the instance as self.ssl_verify in AsyncHTTPHandler.__init__
• Pass ssl_verify=self.ssl_verify in all four retry create_client() calls

aiohttp_handler.py

• Add ssl_verify: Optional[Union[bool, str]] = None parameter to BaseLLMAIOHTTPHandler.__init__
• Store it as self.ssl_verify
• Forward it to AsyncHTTPHandler._create_aiohttp_transport(ssl_verify=self.ssl_verify)

Testing

Both files already have ssl_verify wired through create_client() / _create_aiohttp_transport() for the normal (non-retry) path — this PR makes retries consistent with that existing behaviour.

[greptile-apps]

Greptile Summary

This PR propagates ssl_verify through the retry paths in AsyncHTTPHandler and adds an ssl_verify parameter to BaseLLMAIOHTTPHandler, closing the gap where a connection-error retry would silently reset SSL settings to defaults.

• http_handler.py: self.ssl_verify is now stored in __init__ and forwarded to create_client() in all four retry catch blocks (post, put, patch, delete). The value flows through get_ssl_configuration which correctly handles bool, string CA-bundle paths, and ssl.SSLContext objects.
• aiohttp_handler.py: ssl_verify: Optional[Union[bool, str]] is added to BaseLLMAIOHTTPHandler.__init__ and forwarded to _create_aiohttp_transport. However, _create_aiohttp_transport (and _get_ssl_connector_kwargs) only handle Optional[bool]; a string CA-bundle path would be accepted by the new parameter but silently ignored by the underlying transport, leaving it with default SSL instead of the user's custom CA.

Confidence Score: 3/5

The http_handler.py changes are safe and correct; the aiohttp_handler.py change has a gap where string CA-bundle paths are accepted by the new parameter but silently dropped before reaching the transport.

The AsyncHTTPHandler retry fix is well-scoped and correctly routes through get_ssl_configuration. The BaseLLMAIOHTTPHandler change widens the accepted type to Union[bool, str] at the class boundary, but _create_aiohttp_transport and _get_ssl_connector_kwargs only check ssl_verify is False; a CA-bundle file path is never loaded or applied, so users passing a string to BaseLLMAIOHTTPHandler would silently fall back to default SSL verification instead of their custom CA.

litellm/llms/custom_httpx/aiohttp_handler.py — specifically the _get_or_create_transport path and how string ssl_verify values are not translated into an ssl.SSLContext before being handed to _create_aiohttp_transport

Important Files Changed

Filename	Overview
litellm/llms/custom_httpx/aiohttp_handler.py	Adds ssl_verify to BaseLLMAIOHTTPHandler.init and forwards it to _create_aiohttp_transport; string CA-bundle paths are silently dropped because the underlying _get_ssl_connector_kwargs only handles Optional[bool]
litellm/llms/custom_httpx/http_handler.py	Stores ssl_verify on AsyncHTTPHandler instance and passes it through all four retry create_client() calls; correctly routes through get_ssl_configuration which handles bool, string, and SSLContext values

_{Reviews (1): Last reviewed commit: "fix: propagate ssl_verify through BaseLL..." | Re-trigger Greptile}

[greptile-apps]

String CA-bundle path silently dropped in aiohttp transport

BaseLLMAIOHTTPHandler now advertises ssl_verify: Optional[Union[bool, str]], accepting a CA-bundle file path (e.g. "/etc/ssl/my-ca.pem"). However, _create_aiohttp_transport (and its delegate _get_ssl_connector_kwargs) only handle Optional[bool]; a string value falls through both conditionals (ssl_context is not None and ssl_verify is False) and is silently ignored, leaving the transport with default SSL verification instead of the user's custom CA. Contrast this with AsyncHTTPHandler.create_client, which calls get_ssl_configuration(ssl_verify) first and properly converts a path to an ssl.SSLContext before configuring the transport. The aiohttp path should do the same.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!