Nightly dependency update: OpenTelemetry 1.42.1/0.63b1#762
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
This automated dependency update bumps OpenTelemetry from 1.40.0/0.61b0 to 1.42.1/0.63b1, skipping the intermediate 1.41.0/0.62b0 release (which is noted as having breaking changes).
Issues Found
-
opentelemetry-instrumentation-threadingleft at 0.61b0 (likely bug) — Every other contrib instrumentation package is updated from 0.61b0 → 0.63b1, butopentelemetry-instrumentation-threadingremains pinned at 0.61b0. This version mismatch will likely cause dependency resolution failures because OTel instrumentation packages typically have tight peer-dependency constraints onopentelemetry-instrumentation(which is being updated to 0.63b1). This is probably the cause of the CI failure noted in the PR description. -
Breaking changes from skipped release not addressed — The PR body mentions that v0.62b0 of opentelemetry-python-contrib included breaking changes, but doesn't detail what they are or confirm that no code changes are needed in this repo. Given the CI failure, it's worth investigating whether any API changes from the skipped release require code updates.
No security issues identified — this is a straightforward version bump of well-known dependencies.
|
Claude finished @liustve's task in 1m 35s —— View job PR ReviewI re-checked this PR against the existing review. The findings are unchanged, so I'm not re-posting them — see the existing review thread for details.
Summary of stateStill outstanding (already flagged in the prior review):
No new issues: the other five files ( No security concerns — straightforward version bumps of well-known dependencies. |
|
Claude finished @liustve's task in 1m 8s —— View job PR ReviewI re-checked this PR against the existing review. The findings are unchanged, so I'm not re-posting them — see the existing review thread for details.
Summary of stateStill outstanding (already flagged in the prior review):
No new issues: the other five files ( No security concerns — straightforward version bumps of well-known dependencies. |
|
Claude finished @liustve's task in 1m 19s —— View job PR ReviewI re-checked this PR against the existing review. The findings are unchanged, so I'm not re-posting them — see the existing review thread for details.
Summary of stateStill outstanding (already flagged in the prior review):
No new issues: the other five files ( No security concerns — straightforward version bumps of well-known dependencies. · branch |
The legacy boto2 instrumentation was removed from opentelemetry-python-contrib in 0.62b0 (open-telemetry/opentelemetry-python-contrib#4303). Pinning it at 0.63b1 breaks pip resolution.
|
Claude finished @liustve's task in 2m 29s —— View job PR ReviewI re-checked this PR against the existing review. The findings are unchanged, so I'm not re-posting them — see the existing review thread for details.
Summary of stateStill outstanding (already flagged in the prior review):
New since the prior review: commit No new issues in the other files ( No security concerns — straightforward version bumps of well-known dependencies. · branch |
opentelemetry-python 1.42.0 and opentelemetry-python-contrib 0.63b0 dropped Python 3.9 support, so ADOT cannot install on it either. - Bump requires-python to >=3.10 across distro and contract tests - Remove 3.9 from tox envlist and CI test matrices (pr-build, run-instrumentation-tests) - Drop py39 e2e jobs (default + asg + arm64); add py310 platform/arch coverage - Delete .coveragerc-py39 and the 3.9 branch in set_up action - Narrow DI bytecode-injection engine to Python 3.10-3.11 (rename helper, bump version checks, refresh comments) - Pin pytest>=9 in dev-requirements (was pinned to <10 for 3.9)
PR Review
|
PR Review
|
PR Review
|
|
Claude finished @liustve's task in 2m 40s —— View job PR ReviewI re-checked this PR against the existing review. The earlier blocker is resolved; no new substantive issues to flag.
Summary of stateResolved since the prior review:
New since the prior review (clean):
Still outstanding (already flagged in the prior review, not re-posting):
No security concerns — straightforward version bumps and tooling additions. · branch |
|
Claude finished @liustve's task in 2m 34s —— View job PR ReviewI re-checked this PR against the existing review. No new substantive issues to flag.
Summary of stateNew since the prior review (clean):
Earlier blocker remains resolved: Still outstanding (already flagged in the prior review, not re-posting):
Note on residual risk: since the latest push, CI is in progress (PR build + DI contract tests) — CodeQL is the only completed check so far. If those new runs pass, the dependency-resolution and breaking-change concerns are effectively addressed in practice. No security concerns — straightforward version bumps, Python-version-floor cleanup, and tooling additions. |
liustve
force-pushed
the
nightly-dependency-updates
branch
from
a7c7d83 to
b07d0f4
Compare
|
Claude finished @liustve's task in 2m 57s —— View job PR ReviewI re-checked this PR against the existing review. No new substantive issues to flag.
Summary of stateNo new commits since the prior review at 23:40 UTC — Earlier blocker remains resolved: CI signal (positive): the install-stage jobs that previously failed instantly with Still outstanding (already flagged in the prior review, not re-posting):
No security concerns — straightforward version bumps, Python-version-floor cleanup, and tooling additions. · branch |
Threading was the lone instrumentation pinned at 0.61b0, transitively requiring opentelemetry-instrumentation==0.61b0, which conflicted with the ==0.63b1 pin coming from every other 0.63b1 instrumentation. Caused all CI build/test jobs to fail at pip install with ResolutionImpossible.
liustve
force-pushed
the
nightly-dependency-updates
branch
from
b07d0f4 to
7255e74
Compare
|
Claude finished @liustve's task in 8m 7s —— View job PR ReviewI re-checked this PR against the existing review. One new substantive finding to flag — a follow-up tooling issue that was claimed resolved in earlier summaries but is not actually present in current
Summary of state
Earlier blocker remains resolved in New since the prior review (regression — was reported resolved, but isn't):
Other changes since the prior review (clean):
Still outstanding (already flagged in prior reviews, not re-posting):
CI signal: as of this run, No security concerns — version bumps, Python-floor cleanup, and an instrumentation-package removal of well-known dependencies. · branch |
OTel core 1.42.0 dropped the third-party `importlib-metadata` dependency in favor of the stdlib `importlib.metadata` since the project now requires Python >= 3.10 (open-telemetry/opentelemetry-python#3234). With OTel upgraded but `importlib-metadata` no longer transitively installed, the ADOT configurator's import fails with ModuleNotFoundError at test collection time on every supported Python version.
Upstream contrib 0.63b1 refactored the botocore extension API: - _KNOWN_EXTENSIONS split into _BOTOCORE_EXTENSIONS + _AIOBOTOCORE_EXTENSIONS (to support the new aiobotocore instrumentation added in 0.62b0) - _find_extension removed; lookup now goes through an ExtensionRegistry instance attached to the instrumentor as self.extension_registry - _safe_invoke moved from opentelemetry.instrumentation.botocore to opentelemetry.instrumentation.botocore.utils Update ADOT's _botocore_patches.py to: - import _BOTOCORE_EXTENSIONS instead of _KNOWN_EXTENSIONS - import _safe_invoke from the new utils module - replace _find_extension() with self.extension_registry.get_extension() - replace _get_tracer/_get_meter/_get_metrics/_get_logger calls with the registry-method equivalents (and drop the redundant _get_meter — metrics are now fetched directly without a meter intermediary) Tests in test_instrumentation_patch.py patch the new ExtensionRegistry.get_extension/get_tracer/get_logger/get_metrics methods on the registry class instead of the module-level lookups that no longer exist.
Contrib 0.62b0 merged opentelemetry-python-contrib#4375 which makes the ASGI middleware respect the suppress_http_instrumentation context natively to skip server span creation when HTTP instrumentation is suppressed. The ADOT patch carried a TODO pointing to that PR and is now upstream behavior. Remove the patched __call__ method and the matching test. The exclude_receive_span/exclude_send_span patch above is kept since its tracking issue (#3725) is still open.
|
LGTM.
|
The SDK's increment_hit_count uses `hit_count > config.max_hits` for the disable check (instrumentation_manager.py:631), so MaxHits=N emits N snapshots and disables on the (N+1)th hit. The DI Flask, FastAPI, and Django hit-limit contract tests expected N-1 snapshots, claiming the check was `>=` in their docstrings and inline comments — neither matched the SDK. The tests were passing on main by accident: BatchLogRecordProcessor's default schedule_delay_millis was 5000ms, so the snapshot emitted on the 3rd hit was still sitting in the batch buffer when the test's 2-second sleep elapsed and read the collector. core 1.41.0 tightened the default to 1000ms (open-telemetry/opentelemetry-python#4998), shrinking the window enough that the 3rd snapshot now lands before the test reads. Fix the tests (and the docstrings on the application's target functions) to match SDK behavior: MaxHits=3 -> 3 snapshots emitted, breakpoint disables on the 4th hit. Send a 4th request to actually probe the disabled state, and widen the disabled-state observation window to 5s so any spurious 4th snapshot has plenty of time to flush before we assert the breakpoint stayed disabled.
) ## Summary The DI Flask `DIFlaskHitLimitTest` and the matching application target function had `MaxHits` semantics flipped relative to the SDK. With `MaxHits=3`, the test expected 2 snapshots, claiming the disable check was `hit_count >= max_hits`. The SDK's [increment_hit_count](https://github.com/aws-observability/aws-otel-python-instrumentation/blob/main/aws-opentelemetry-distro/src/amazon/opentelemetry/distro/debugger/instrumentation_manager.py#L631) actually uses `hit_count > max_hits`, so it emits 3 snapshots and disables on the 4th hit. ## Why this is surfacing now The test was passing on main by accident. `BatchLogRecordProcessor`'s default `schedule_delay_millis` was 5000ms, so the snapshot emitted on the 3rd hit was still sitting in the batch buffer when the test's `time.sleep(2)` elapsed and read the collector. The 3rd snapshot never reached the mock collector within the test's observation window. OpenTelemetry core 1.41.0 [tightened that default to 1000ms](open-telemetry/opentelemetry-python#4998) to comply with the OTel spec, so the upcoming dependency bump to 1.42.1 / 0.63b1 (#762) now sees the 3rd snapshot consistently and the latent off-by-one assertion fails the test. ## Changes - Update the test class docstring and both test methods so `MaxHits=3` → 3 snapshots, breakpoint disabled on the 4th hit. Send a 4th request to actually probe the disabled state. - Update the `limited_function` docstring in the di-flask sample app to match. ## Test plan - [ ] DI Debugger Contract Tests pass on this branch (currently the only test in the suite that was failing, on the `nightly-dependency-updates` branch) - [ ] No SDK behavior change — purely a test/comment alignment with current SDK semantics
|
Claude finished @liustve's task in 5m 10s —— View job PR ReviewI re-checked this PR against the latest review feedback and prior findings.
Status of @ezhang6811's requested follow-ups
Other still-outstanding findings (already flagged previously, not re-posted on the line)
What's clean
No security concerns — straightforward version bumps and Python-floor cleanup. · branch |
… 3.10) (#643) ## Why The nightly OpenTelemetry dependency bump in `aws-otel-python-instrumentation` ([PR #762](aws-observability/aws-otel-python-instrumentation#762), OTel `1.42.1` / `0.63b1`) raised the ADOT distro's minimum to **Python ≥ 3.10**: - `opentelemetry-api`: `1.41.1` was `requires_python >=3.9` → `1.42.1` is **`>=3.10`** - `opentelemetry-instrumentation-*`: `0.62b1` was `>=3.9` → `0.63b1` is **`>=3.10`** The `python-ec2-adot-sigv4` and `python-ec2-adaptive-sampling` E2E jobs default to **Python 3.9**, so after the bump pip on the EC2 host could no longer resolve the pinned distro: ``` ERROR: Could not find a version that satisfies the requirement opentelemetry-api==1.42.1 ... ERROR: No matching distribution found for opentelemetry-instrumentation-celery==0.63b1 nohup: failed to run command 'opentelemetry-instrument': No such file or directory ``` This turned the **Python Instrumentation Main Build** red on every run starting 2026-06-17 01:26 UTC (first failure = the dep-bump commit; the run immediately before it was green). The `default` EC2 matrix (3.10–3.14) and container/layer-based jobs were unaffected because they don't pip-install the pinned distro on a 3.9 interpreter. > Note: the `k8s-py310-amd64` job also fails intermittently, but that is a **separate, pre-existing** CloudWatch observability controller-manager pod-readiness timeout — unrelated to this change. ## What Removes **all** Python 3.8/3.9 references from the Python test framework and floors everything at 3.10: - **Reusable workflows** — `python-version` default `3.9` → `3.10` (`default`, `asg`, `lambda`, `adot-sigv4`); normalized "currently supported" description strings to `3.10, 3.11, 3.12, 3.13, 3.14` across all Python workflows. - **adaptive-sampling** — hardcoded `python3.9` install command → `python3.10`. - **Terraform** — `language_version` default `3.9` → `3.10` (`default`, `asg`, `adot-sigv4`, `adaptive-sampling`). - **EC2 user-data scripts** — dropped the now-dead `== "3.8"` conditional branches and 3.8 comment references; fixed a pre-existing `3,10` comment typo. - **ECR sample-app deploy** — removed `3.8` and `3.9` from the build matrix. ## Testing - All 9 modified workflow YAML files validated as well-formed. - `terraform fmt -check` passes on all four modified EC2 dirs (no diff). - Repo-wide grep confirms no remaining `3.8`/`3.9`/`python3.8`/`python3.9` references in the Python framework.
Resolve conflicts by keeping the interpreter-layer instrumentation engine (bytecode / sys.monitoring) and dropping the framework-specific patching code that landed on main after this branch forked. The engine mutates a function's __code__ in place, so any reference a framework holds (Flask view_functions, Django URLPattern.callback, FastAPI route table / Depends sub-dependencies, `from x import f` aliases) sees the rewritten code on the next call — no per-framework patcher needed. Production code removed (reverted from main): - _patch_framework_references / _patch_flask_view_functions / _patch_single_flask_app - _patch_django_url_patterns / _patch_single_resolver / _maybe_patch_pattern - _patch_fastapi_routes / _patch_single_fastapi_app (incl. Depends rebind) - _patch_module_aliases / _is_application_module / _stdlib_lib_dirs (aws-observability#776, aws-observability#780, aws-observability#785, aws-observability#786) Tests: - Behavioral contract tests (di/django_test.py, di/fastapi_test.py, di/flask_test.py) kept as-is — they validate end-to-end that everything still works through the engine with no patching. - White-box unit tests that called the deleted _patch_* methods directly (test_function_wrapper_django.py, test_function_wrapper_fastapi.py, TestModuleAliasRedirect) rewritten 1:1 to drive the engine — same scenarios, only the operative call changed (mirrors how this branch already rewrote test_function_wrapper_flask.py). - Dropped only the tests of deleted internals with no engine equivalent: the _patch_framework_references dispatcher tests, the resolver-walk error-branch tests, and TestIsApplicationModule. Also adopt main's "drop Python 3.9" change (aws-observability#762): engine and manager gate on >= 3.10; function-level builders renamed _39_310 -> _310; 3.9 references removed across src and tests. Kept main's non-patching debugger improvements: capture-limit default constants (aws-observability#771), instrumentation_name field removal (aws-observability#775), OTel 1.42.1 bump (aws-observability#762), and the capture-limits test.
5 participants
Automated update of OpenTelemetry dependencies.
Build Status: ❌ failure
Updated versions:
Upstream releases with breaking changes:
Note: the mechanism to detect upstream breaking changes is not perfect. Be sure to check all new releases and understand if any additional changes need to be addressed.
opentelemetry-python-contrib:
Description of changes:
Drops the
opentelemetry-instrumentation-botoruntime dependency (legacy boto2 instrumentation), removed entirely upstream in: Remove boto instrumentation open-telemetry/opentelemetry-python-contrib#4303Drops Python 3.9 support to match upstream's new minimum (Python ≥3.10): Drop Python 3.9 support open-telemetry/opentelemetry-python#5076 (core) and Drop Python 3.9 support open-telemetry/opentelemetry-python-contrib#4412 (contrib)
Switches
from importlib_metadata import versionto stdlibfrom importlib.metadata import versionafter upstream dropped the third-partyimportlib-metadatapackage fromopentelemetry-api:importlib-metadatabreaks code open-telemetry/opentelemetry-python#3234Refactors the botocore patches (
_botocore_patches.py) to use the newExtensionRegistryAPI. Upstream split_KNOWN_EXTENSIONSinto_BOTOCORE_EXTENSIONS+_AIOBOTOCORE_EXTENSIONS, removed_find_extension, and moved_safe_invoketoopentelemetry.instrumentation.botocore.utilsas part of adding aiobotocore instrumentation: feat: add support for aiobotocore instrumentation open-telemetry/opentelemetry-python-contrib#4049Removes the Starlette ASGI
suppress_http_instrumentationpatch (which the existing ADOT TODO already flagged) since the ASGI middleware now natively honorssuppress_http_instrumentationupstream: feat(asgi): respect suppress_http_instrumentation in ASGI middleware open-telemetry/opentelemetry-python-contrib#4375Adapts the configurator tests to upstream's renamed
BaggageSpanProcessor._baggage_key_predicate→_predicates(now a list of callables, after the constructor was reworked to accept either a single predicate or a sequence): feat: Add BaggageLogProcessor to opentelemetry-processor-baggage open-telemetry/opentelemetry-python-contrib#4371Adapts
test_otlp_attribute_vs_body_typesto upstream's_VALID_ANY_VALUE_TYPESswitchingtyping.Mapping/typing.Sequencetocollections.abc.Mapping/collections.abc.Sequence: chore: apply fixes for UP ruff rule open-telemetry/opentelemetry-python#5133Bumps the mysqlclient contract-test pin from
2.2.4to2.2.8and updates the matchingdb.nameassertion. The 0.62b0 dbapi semantic-convention migration (DB semantic convention stability migration for DB-API and 7 inheriting db client instrumentors open-telemetry/opentelemetry-python-contrib#4109) added an empty-string filter inside_set_db_name, which exposed a latent gap: mysqlclient < 2.2.7 didn't expose a Python-levelconn.dbattribute (added upstream in add database name as the Connection attribute PyMySQL/mysqlclient#752, shipped in mysqlclient 2.2.7), so OTel's dbapi instrumentation defaulteddatabaseto""and the empty value used to land on the span unconditionally. After 0.62b0 the empty value is dropped, so the assertiondb.name == ""now fails with "key not found". Bumping mysqlclient letsconn.dbflow through as the actual database name (testdb) so the assertion becomes meaningful.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.