Raise agnostic HTTP exceptions and narrow integration catch sites

[mwdd146980]

What does this PR do?

Establishes the backend-agnostic exception floor for the httpx migration: the shared HTTP wrapper in datadog_checks_base raises library-neutral exception types, and the integrations that catch HTTP errors are moved onto those types in the same change.

Note on the openstack integration: This integration specifically has some bugs that AI reviewers may flag, but given that it is legacy/deprecated in favor of the openstack_controller integration, we've decided to preserve existing behavior.

Motivation

Integrations today catch requests.exceptions.* directly, which couples every check to the HTTP library and blocks any incremental move to httpx. Translating errors once, in the wrapper, turns the underlying library into an implementation detail: integrations catch stable, neutral exceptions and won't need to change again when the transport is swapped.

The base change and the integration updates are inseparable. The moment the wrapper stops emitting requests.exceptions.*, any catch site still keyed to those types silently stops matching, for example a health check that quietly fails to report CRITICAL. Shipping them together, and on the mwdd146980/httpx-migration-base feature branch rather than master, guarantees no Agent release is ever exposed to that half-migrated state.

Verification

Base and per-integration unit suites pass; openstack was additionally verified locally. Docker-gated suites rely on CI. Run ddev test -fs datadog_checks_base for the base package.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add qa/required if this PR needs QA validation, or qa/skip-qa if it does not. Exactly one of the two is required.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[datadog-official]

   

✨ Fix all issues with BitsAI

⚠️ Warnings

🚦 2 Pipeline jobs failed

PR All | test / j06ca546 / SNMP     

PR All | test / jeebd4ae / Kubernetes Scheduler     

🧪 2 Tests failed in 1 job

PR All | run  

test_e2e from test_e2e.py  

Needed exactly 2 candidates for 'kube_scheduler.prometheus.health', got 0
Expected:
        ServiceCheckStub(check_id=None, name='kube_scheduler.prometheus.health', status=2, tags=['endpoint:http://localhost:10251/metrics'], hostname=None, message=None)
Difference to closest:


Similar submitted:
Score   Most similar

❄️ Known flaky: test_e2e_snmp_listener from test_e2e_snmp_listener.py  

Needed at least 1 candidates for 'datadog.snmp.check_duration', got 0
Expected:
        MetricStub(name='datadog.snmp.check_duration', type=0, value=None, tags=['autodiscovery_subnet:172.18.0.0/28', 'device_vendor:apc', 'firmware_version:2.0.3-test', 'loader:python', 'model:APC Smart-UPS 600', 'serial_num:test_serial', 'snmp_device:172.18.0.1', 'snmp_profile:apc_ups', 'ups_name:testIdentName'], hostname=None, device=None, flush_first_value=None)
Difference to closest:
        Expected tag snmp_device:172.18.0.1
        Found snmp_device:172.18.0.2

Similar submitted:
Score   Most similar
1.00    MetricStub(name='datadog.snmp.check_duration', type=0, value=0.16432833671569824, tags=['autodiscovery_subnet:172.18.0.0/28', 'device_vendor:apc', 'firmware_version:2.0.3-test', 'loader:python', 'model:APC Smart-UPS 600', 'serial_num:test_serial', 'snmp_device:172.18.0.2', 'snmp_profile:apc_ups', 'ups_name:testIdentName'], hostname='runnervmos4r4', device=None, flush_first_value=False)
...

Not introduced in this PR.

ℹ️ Info

No other issues found (see more)

❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 89.33%
• Overall Coverage: 88.37% (+0.01%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: aec3f5a | Docs | Datadog PR Page | Give us feedback!}

[triviajon]

Migrating to generic HTTP erros in the openmetrics scraper LGTM

[triviajon]

Is this intentional?

[mwdd146980]

yes, basically because transport failures are translated as HTTPRequestError or a subclass here and that no longer subclasses IOError, but it's still possible for an IOError to be raised (e.g. FileNotFoundError)

[dd-octo-sts]

Validation Report

All 21 validations passed.

Show details

Validation	Description	Status
agent-reqs	Verify check versions match the Agent requirements file	✅
ci	Validate CI configuration and code coverage settings	✅
codeowners	Validate every integration has a CODEOWNERS entry	✅
config	Validate default configuration files against spec.yaml	✅
dep	Verify dependency pins are consistent and Agent-compatible	✅
http	Validate integrations use the HTTP wrapper correctly	✅
imports	Validate check imports do not use deprecated modules	✅
integration-style	Validate check code style conventions	✅
jmx-metrics	Validate JMX metrics definition files and config	✅
labeler	Validate PR labeler config matches integration directories	✅
legacy-signature	Validate no integration uses the legacy Agent check signature	✅
license-headers	Validate Python files have proper license headers	✅
licenses	Validate third-party license attribution list	✅
metadata	Validate metadata.csv metric definitions	✅
models	Validate configuration data models match spec.yaml	✅
openmetrics	Validate OpenMetrics integrations disable the metric limit	✅
package	Validate Python package metadata and naming	✅
qa-label	Validate the pull request declares whether it needs QA for the next Agent release	✅
readmes	Validate README files have required sections	✅
saved-views	Validate saved view JSON file structure and fields	✅
version	Validate version consistency between package and changelog	✅

View full run