Fix: Address-family mismatch confirmed: the shared mock server in test_otlp_e - #5530
Open
M001N wants to merge 1 commit into
Open
Fix: Address-family mismatch confirmed: the shared mock server in test_otlp_e#5530M001N wants to merge 1 commit into
M001N wants to merge 1 commit into
Conversation
…tname The mock gRPC server used by test_otlp_exporter_mixin.py binds only to the IPv4 loopback address (127.0.0.1), but the tests that actually exercise real connections to that server relied on the exporter's default endpoint, which resolves the ambiguous hostname 'localhost'. On environments where 'localhost' resolves to the IPv6 loopback address (::1) first, the exporter would try to connect to whatever (if anything) is listening on ::1:4317 instead of the mock server, causing confusing, environment-dependent test failures/hangs. Give OTLPSpanExporterForTesting an explicit default endpoint of http://127.0.0.1:4317 (only applied when the test doesn't already pass its own endpoint, e.g. test_otlp_exporter_endpoint), matching the address the mock server actually binds to. Update the couple of assertions that hard-coded the old 'localhost:4317' string for exporters that now connect via 127.0.0.1. Tests in test_otlp_trace_exporter.py and test_otlp_metrics_exporter.py only assert against mocked channels (never make a real connection) and still validate the production default endpoint value, so they are left untouched. Assisted-by: Claude Sonnet 5
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Gave the test-only OTLPSpanExporterForTesting helper class (in test_otlp_exporter_mixin.py) a default endpoint of "http://127.0.0.1:4317" via kwargs.setdefault, applied only when a test doesn't already pass its own endpoint (so test_otlp_exporter_endpoint, which explicitly parametrizes endpoint/insecure combinations, is unaffected). This makes every real-connection test target the same IPv4 address the mock server binds to, eliminating the address-family mismatch. Updated the handful of assertions that hard-coded the old 'localhost:4317' string (two warning-log message checks, two mocked insecure_channel call assertions, and the server.address metric attribute check) to expect 127.0.0.1:4317 / 127.0.0.1, since those exporters now genuinely resolve to that address. Production default endpoint values in exporter.py were not touched. test_otlp_trace_exporter.py and test_otlp_metrics_exporter.py only assert against mocked gRPC channels (never make a real socket connection) and are verifying the production default endpoint value, so they were left unchanged as instructed.
Problem
open-telemetry/opentelemetry-python issue reference: #4062
Root Cause
Address-family mismatch confirmed: the shared mock server in test_otlp_exporter_mixin.py binds explicitly to the IPv4 loopback (127.0.0.1:4317), but tests exercising real exports rely on the exporter's default endpoint resolution of the ambiguous hostname 'localhost', which can resolve to the IPv6 loopback (::1) first depending on OS/DNS/hosts configuration. This is purely a test-fixture issue, not a production defect.
Testing
PASS - all 51 tests passed, 5 skipped (Windows-only timing skips, pre-existing and unrelated to this fix)
Related Issue
#4062