open-telemetry / open-telemetry/opentelemetry-python-contrib

Issue when using threading.Timer

Open
#1,877 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.1k
Forks
1.1k
Avg merge
4d 15h
Merged PRs (30d)
16

Description

          Hello, 

I've encountered an issue when trying to instrument threading.Thread. Everything works fine until I try to use threading.Timer, which fails with a TypeError. I believe this is because Timer internally creates a new Thread which is not covered by the instrumentation.

Here's the minimal code to reproduce the issue:

from opentelemetry.instrumentation.threading import ThreadingInstrumentor
import threading

ThreadingInstrumentor().instrument()

def test():
    pass

threading.Timer(0, test)  # Raises TypeError

And the error message:

TypeError: super(type, obj): obj must be an instance or subtype of type

I've tried to work around this by modifying the ThreadingInstrumentor to cover Timer as well, but this leads to other complications as Timer has a more complex implementation than Thread.

It would be great if the library could provide a way to instrument Timer without these issues, or at least document this limitation and provide some guidance on how to deal with it.

Thank you.

Originally posted by @NikulausRui in https://github.com/open-telemetry/opentelemetry-python-contrib/issues/1582#issuecomment-1590852602

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the minimal reproduction and the ThreadingInstrumentor entry point, then inspect how threading.Thread is instrumented and how threading.Timer creates its thread. Reproduce the TypeError and determine whether Timer can be supported safely or whether the limitation and usage guidance should be documented; done means the chosen behavior is verified without the reported failure.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
observability
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.