fix: Add DNSResolutionError for handling DNS resolution failures

[devin-ai-integration]

Description

This PR adds a new DNSResolutionError class to handle DNS resolution failures while maintaining security checks for invalid URLs. This addresses issue airbytehq/airbyte-internal-issues#11320.

Key changes:

• Add DNSResolutionError class for DNS resolution failures
• Keep InvalidURL as a config error for security validation
• Add test coverage for both DNS resolution errors and invalid URLs

Link to Devin run: https://app.devin.ai/sessions/6b54ed98f6e84226b1f5a7cb2d1a941d
Requested by: AJ

[devin-ai-integration]

🤖 Devin AI Engineer

Original prompt from Aaron:

Received message in Slack channel #ask-devin-ai:

@Devin - Can you help me get started on this issue? <https://github.com/airbytehq/airbyte-internal-issues/issues/11320>

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add "(aside)" to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[aaronsteers]

I don't see where this exception class is raised. Can you help me understand this?

Does our code need to raise this exception in order for its handling to trigger? Or is it going to be picked up automatically somehow?

[devin-ai-integration]

The DNSResolutionError is raised in http_client.py's _send method when we catch a requests.ConnectionError that contains DNS-related error messages. Here's the relevant code:

try:
    response = self._session.send(request, **request_kwargs)
except requests.ConnectionError as e:
    if "Name or service not known" in str(e) or "nodename nor servname provided" in str(e):
        assert request.url is not None, "Request URL cannot be None for DNS resolution error"
        exc = DNSResolutionError(
            url=request.url, request=request, response=e, error_message=str(e)
        )
    else:
        exc = e

This allows us to distinguish between actual DNS resolution failures (which should be retried) and invalid URLs (which are config errors and should fail immediately). The error handler will then interpret this exception and apply the appropriate retry policy.

[aaronsteers]

Should we only catch InvalidURL exceptions here? It looks like previously, these failures were raised and custom-handled as InvalidURL exceptions.

[devin-ai-integration]

We should catch here rather than because:

1. is raised by requests when a URL is malformed (e.g., missing scheme, invalid characters)
2. DNS resolution errors come as with specific error messages like 'Name or service not known'

The key difference is:

• : Immediate validation failure for malformed URLs (config error)
• with DNS message: Temporary failure to resolve a well-formed URL (transient error)

Previously, both were treated as , but this meant we weren't retrying on temporary DNS failures. This change allows us to:

1. Fail fast on malformed URLs (security/config validation)
2. Retry on temporary DNS resolution issues (improved reliability)

The error handler will then apply the appropriate retry policy based on the specific exception type.

[aaronsteers]

Can you add a test that simulates/mocks the error we expect the http api to raise? Specifically, I think we're expecting something like an invalid URL code, except with the noted error text about DNS.