Skip to content

feat!: bump the lower bound of opentelemetry-instrumentation from 0.43b0 to 0.64b0 - #425

Draft
adubovik wants to merge 6 commits into
developmentfrom
feat/support-new-otel-libs
Draft

feat!: bump the lower bound of opentelemetry-instrumentation from 0.43b0 to 0.64b0 #425
adubovik wants to merge 6 commits into
developmentfrom
feat/support-new-otel-libs

Conversation

@adubovik

Copy link
Copy Markdown
Collaborator

Applicable issues

N/A

Description of changes

The OTel instrumentation packages changed the logging behaviour in 0.61b0, breaking the SDK's telemetry tests. Instead of working around it, the lower bound is bumped to 0.64b0 and the new APIs are used:

  • inject_trace_context=True — adds the otel* fields (otelTraceID, otelSpanID, otelTraceSampled, otelServiceName) to every log record without taking over the logging format. Up to 0.60b1 the instrumentor did it unconditionally; since 0.61b0 it only does so together with the logging.basicConfig() takeover, which the SDK avoids when TracingConfig.logging is off. The kwarg was added in 0.64b0.
  • enable_log_auto_instrumentation — the log handler is now installed by the instrumentor itself instead of opentelemetry.sdk._logs.LoggingHandler, which is deprecated since 1.44 in favour of the one from opentelemetry-instrumentation-logging. Since 0.61b0 the instrumentor installs its own handler by default, so the SDK's handler duplicated every exported log record when both tracing and logs were enabled. The kwarg lets the SDK decide, overriding the OTEL_PYTHON_LOG_AUTO_INSTRUMENTATION env var. The exported payload is unchanged: the handler is a copy of the deprecated one (same WARNING -> WARN mapping, NOTSET level, so no level floor).

The new test_console_export_with_tracing_emits_no_duplicates covers the duplication, which no test caught before.

Checklist

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

🤖 Generated with Claude Code

adubovik and others added 3 commits July 30, 2026 12:29
Bump the lower bound of the OTel instrumentation packages from 0.43b0 to
0.64b0 and use the APIs it provides instead of relying on the behaviour
which changed in 0.61b0:

* `inject_trace_context=True` adds the `otel*` fields to log records
  without taking over the logging format - the instrumentor stopped
  doing it unconditionally in 0.61b0,
* the log handler is installed by the instrumentor itself
  (`enable_log_auto_instrumentation`) instead of the one from
  `opentelemetry.sdk._logs`, which is deprecated since 1.44 and
  which used to duplicate every exported log record.

Reverts the matrix of OTel versions in the noxfile: the SDK now supports
the single generation of the libraries.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@adubovik adubovik changed the title feat: bump the lower bound of opentelemetry-instrumentation from 0.43b0 to 0.64b0 feat!: bump the lower bound of opentelemetry-instrumentation from 0.43b0 to 0.64b0 Jul 31, 2026
adubovik and others added 3 commits August 3, 2026 10:56
The instrumentor is a singleton, so the second `instrument()` call was a
no-op guarded by `config.tracing is None` - hard to reason about. Collapse
both calls into one, placed after `set_logger_provider()` so the log handler
binds to an already-set logger provider.

`set_logging_format` is now suppressed when `console_export` is on: OTel's
console exporter takes over stderr, so the text format installed by
`logging.basicConfig()` was removed again by the logs branch anyway.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant