[Bug] opentelemetry-api 1.45 removed `_ExtendedAttributes`, and CI can't resolve 1.45 to notice
Los mantenedores suelen responder en 1 día
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 56/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- python
- Área
- developer-experience, testing
Línea de trabajo
Read temporalio/contrib/opentelemetry/_logger_provider.py and tests/contrib/opentelemetry/test_logger_provider.py, then check how the dependency lock and test-latest-deps resolve OpenTelemetry alongside google-adk. Confirm the typing and test collection failures against opentelemetry-api 1.45. Decide how to cover the newer API despite the shared dependency cap; done when the provider checks and tests work with 1.45 and CI can detect this compatibility gap.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What are you really trying to do?
Use temporalio.contrib.opentelemetry with opentelemetry-api 1.45, which the opentelemetry extra allows (>=1.26,<2).
Describe the bug
opentelemetry-api 1.45.0 removed the private alias opentelemetry.util.types._ExtendedAttributes. LoggerProvider.get_logger now annotates attributes as Attributes.
temporalio/contrib/opentelemetry/_logger_provider.pyimports it underTYPE_CHECKINGforReplaySafeLoggerProvider.get_logger. Importing the module still works, but pyright, basedpyright and mypy all report the import on 1.45.tests/contrib/opentelemetry/test_logger_provider.pyimports it at runtime, so the module fails to import on 1.45 and none of its tests run.
CI doesn't see this. google-adk>=2.8.0 requires opentelemetry-sdk>=1.39,<=1.42.1, and the project's lock resolves every extra together, so opentelemetry stays at 1.42.1 everywhere. That includes test-latest-deps, which resolved and installed opentelemetry-api==1.42.1 on the October 27 run. test_wrapper_abc_drift.py is meant to catch new ABC methods there, but it can't while that cap holds.
The runtime break from the same release, the new abstract Logger.enabled method, is a separate PR I'm opening alongside this issue.
Minimal Reproduction
On main (64b7005):
$ uv lock --dry-run -P opentelemetry-api==1.45.1 -P opentelemetry-sdk==1.45.1
× No solution found when resolving dependencies ...
╰─▶ Because google-adk>=2.8.0 depends on opentelemetry-sdk>=1.39,<=1.42.1 ...
With only opentelemetry-api installed, 1.44.0 imports the alias and 1.45.1 doesn't:
$ pip install opentelemetry-api==1.45.1
$ python -c "from opentelemetry.util.types import _ExtendedAttributes"
ImportError: cannot import name '_ExtendedAttributes' from 'opentelemetry.util.types'
test_logger_provider.py runs that import at module level, so on 1.45 it fails at collection. I'd expect it to collect and run, as it does with 1.42.1.
Environment/Versions
- OS and processor: macOS, Apple Silicon
- Temporal Version: temporalio 1.34.0 and
main(64b7005), Python 3.12, opentelemetry-api and opentelemetry-sdk 1.45.1 - Are you using Docker or Kubernetes or building Temporal from source? Neither
Additional context
Typing attributes as Any in the override and in the test's provider checks against both the older _ExtendedAttributes signature and the 1.45 Attributes one, at the cost of the precise type. While the shared resolution stays capped, an isolated check against the latest opentelemetry could cover the gap the drift test can't see. I can send a PR for the annotation once you pick a direction, or follow a different one if you'd rather keep a precise type.
- Lenguaje dominante
- Python
- Estrellas
- 1.2k
- Forks
- 276
- Merge medio
- 2 d 2 h
- PR fusionados (30 d)
- 87
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de temporalio/sdk-python
-
[Bug] lambda_worker otel.apply_defaults leaks a span exporter thread and gRPC channel on every warm invocationPosiblemente ocupada @avanish-garg la tomó hoy. Abiertobug sdk-python
Dificultad 4/5 1-2 días Aptitud para principiantes 30/100
temporalio/sdk-python#2040 ·
Los mantenedores suelen responder en 1 día
-
Cloud CI Skips Nexus TestsQuizá libre de nuevo @tconley1428 la tomó hace 79 días y no hay ningún pull request abierto. Abierto
temporalio/sdk-python#1704 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Windows ARM64 wheel supportAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
temporalio/sdk-python#1592 · 8 comentarios ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
temporalio/sdk-python#1578 · 2 comentarios · 2 reacciones ·
Los mantenedores suelen responder en 1 día
-
[Bug] Headers should always run through external storageQuizá libre de nuevo @jmaeagle99 la tomó hace 115 días y no hay ningún pull request abierto. Abiertobug
temporalio/sdk-python#1395 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de temporalio/sdk-python
Issues similares
-
changelog investigate
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
ramnes/notion-sdk-py#433 ·
-
docs pkg:core
Dificultad 1/5 Menos de una hora Aptitud para principiantes 84/100
pydantic/pydantic-ai#11929 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
intake/intake-esm#789 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
MemMachine/MemMachine#1877 ·
Los mantenedores suelen responder en 3 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
openedx/openedx-authz#579 ·
Los mantenedores suelen responder en 1 día