Issues with OTEL Autoinstrumentation

[golgor]

If you are still having issues, please be sure to include as much information as possible:

Environment details

• OS type and version: https://hub.docker.com/layers/library/python/3.12-bookworm/images/sha256-6cb0117e8aaf135dcafa34f1d9498ce4c80e01e1a9933d59100271c8620866f4
• Python version: 3.12.10
• uv version: 0.6.3
• google-cloud-pubsub version: 2.29.0

Steps to reproduce

We have a "Backend" deployed in Kubernetes that rely on Google Pubsub. We use Google Pubsub to relay data between different parts of our Monolith. I was doing the casual updates of packages, where google-cloud-pubsub 2.28.0 -> 2.29.0 was one of them.

I noticed a lot of errors mentioning Pubsub, so I reverted to 2.28.0, and all error disappeared.

Snippets of Stack trace:

Exception in thread Thread-CommitBatchPublisher

Traceback (most recent call last):
  File "/usr/local/lib/python3.12/threading.py", line 1075, in _bootstrap_inner
    self.run()

  File "/otel-auto-instrumentation-python/wrapt/wrappers.py", line 669, in __call__
    return self._self_wrapper(self.__wrapped__, self._self_instance,

  File "/app/.venv/lib/python3.12/site-packages/google/cloud/pubsub_v1/publisher/client.py", line 295, in _gapic_publish
    return super().publish(*args, **kwargs)

  File "/app/.venv/lib/python3.12/site-packages/grpc/_interceptor.py", line 696, in <lambda>
    thunk = lambda m: self._channel.unary_unary(
TypeError: _InterceptorChannel.unary_unary() takes from 2 to 4 positional arguments but 5 were given

We are using annotations to autoinject instrumentation into our container. It seems that there is a compatibility issue here?

In our deployment:

      annotations:
        instrumentation.opentelemetry.io/inject-python: "true"

This is unfortunately a legacy code base and this seems to involve code that I didn't look into deeply. It does however seem to be something with the 2.29.0, so I just wanted to raise a question about it.

Stack trace

The way our logs are structured it is not really possible to provide a full stack-trace. I can probably try to deploy again and get the full stack trace if necessary.