Add semantic-convention conformance test for the requests instrumentation - #4967
Draft
ocelotl wants to merge 1 commit into
Draft
Add semantic-convention conformance test for the requests instrumentation#4967ocelotl wants to merge 1 commit into
ocelotl wants to merge 1 commit into
Conversation
…tion Check the requests instrumentation against the HTTP semantic conventions using the semantic-conventions-conformance tooling, run through its pytest plugin so a convention violation is an ordinary test failure. The test is a normal pytest test collected by the requests instrumentation's existing test suite: no dedicated tox environment and no separate workflow. requests is an HTTP client, so unlike the Flask (server) scenario the conformance.yaml declares a mock HTTP server (otel-http-mock-server) for the client to call, and the scenario drives the shared client workload at it with RequestsInstrumentor enabled. The scenario exercises this repository's own working-tree requests instrumentation, not a released pin. The tooling is installed from a pinned git ref alongside the other test dependencies (pytest bumped to >= 8, which the tooling requires). The shared conftest that provisions the Weaver binary and the pinned registry on demand, and skips cleanly when they cannot be obtained, is byte-for-byte identical to the one used by the Flask conformance test.
Pull request dashboard statusWaiting on the author · refreshed 2026-08-20 17:54 UTC Move out of draft to request review. Status above doesn't look right?
|
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.
Description
Adds a semantic-convention conformance test for the
requestsinstrumentation, the HTTP-client counterpart of the Flask (server) conformance test in #4966. It runs as an ordinarypytesttest in therequestsinstrumentation's existing test suite (no separate tox environment or workflow): the test drives therequestsinstrumentation over a defined set of HTTP requests against a mock server and checks that the emitted telemetry conforms to the HTTP semantic conventions. A convention violation is a normal test failure.The check reuses the tooling from
open-telemetry/semantic-conventions-conformance(the generic runner, the HTTP domain runner, the mock server, and the HTTP test client) via its pytest plugin, which collects theconformance.yamland turns each scenario into a pytest item. The telemetry is validated with Weaver against a pinned semantic-conventions registry.This is the second instrumentation in a planned series (Flask was first, in #4966): the intent is to add semantic-convention conformance tests to the Python instrumentations where this kind of testing applies, one at a time.
Shared harness / code reuse
The Weaver-and-registry provisioning
conftest.pyis a shared harness kept byte-for-byte identical across instrumentations (the same file as in #4966). Only the per-instrumentation parts differ: the scenario (which turns onRequestsInstrumentor), theconformance.yaml(client shape: it starts the HTTP mock server and runs a client scenario), the client workload, and the pinned tooling lines added to this package'stest-requirements.txt.What it adds
instrumentation/opentelemetry-instrumentation-requests/tests/semconv_conformance/: a client workload that drives the shared request contract with arequests.Session, a scenario that enablesRequestsInstrumentor, aconformance.yaml(client scenario plus aserver:block that runs the mock server), and the sharedconftest.py.requestsinstrumentation'stest-requirements.txt(andpytest>=8, which the tooling requires).Draft status and open points
This is a draft for discussion. Known points, same as #4966:
conftest.pyis to move the provisioning upstream into the conformance tooling itself.Feedback on the approach is welcome.