[vatsrahul1001]

Problem

TestOtelMetrics::test_config_priorities has started failing on main (and the release branches) for the six cases that expect the Airflow config host/port to be used when a case provides no OTEL endpoint env var:

FAILED ...test_config_priorities[protocol_is_ignored_if_no_env_endpoint]
FAILED ...test_config_priorities[use_airflow_config]
FAILED ...test_config_priorities[airflow_config_ipv6_loopback_is_bracketed]
FAILED ...test_config_priorities[airflow_config_ipv6_literal_is_bracketed]
FAILED ...test_config_priorities[airflow_config_already_bracketed_ipv6_is_preserved]
FAILED ...test_config_priorities[airflow_config_ipv4_literal_passes_through_unchanged]
  AssertionError: assert '...127.0.0.1:4318...' == '...breeze-otel-collector:4318...'

The test applied only each case's provided_env_vars on top of the ambient environment via env_vars(...), which overlays but does not clear other OTEL_* vars. The RunsOn CI runners export OTEL_EXPORTER_OTLP_ENDPOINT (resolving to 127.0.0.1:4318) for their own telemetry. For the cases that intentionally provide no endpoint env var, that ambient var leaks in and — correctly, per the config-priority rules — wins over the Airflow config, so the resolved endpoint becomes 127.0.0.1:4318 instead of the expected config host. The test is non-hermetic; the production code is correct.

This is why it fails on main and every release branch at once (the runner env is shared), not a regression in the OTEL code.

Fix

Clear all OTEL_* env vars (via monkeypatch.delenv) before applying the case's provided_env_vars, so the test only ever sees its own inputs regardless of the runner environment.

Testing

Reproduced the exact six failures locally by exporting OTEL_EXPORTER_OTLP_ENDPOINT, then confirmed all cases pass with the fix in place even with the ambient var set:

OTEL_EXPORTER_OTLP_ENDPOINT=http://127.0.0.1:4318 \
  pytest shared/observability/.../test_otel_logger.py::TestOtelMetrics::test_config_priorities
# 10 passed

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines

[github-actions]

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.4.1 based on: backport label targeting v3-4-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test