open-telemetry / open-telemetry/opentelemetry-python

LoggingHandler can be initialized in a bad state, has type checking problems

Open
#4,582 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
2.6k
Forks
1k
Avg merge
4d 15h
Merged PRs (30d)
19

Description

Describe your environment

No response

What happened?

The SDK LoggingHandler can be initialized in a bad state by doing just handler = LoggingHandler().

When i do this:

from opentelemetry.sdk._logs import LoggingHandler
import logging

handler = LoggingHandler()
logging.getLogger().addHandler(handler)
logger1 = logging.getLogger("myapp.area1")
logger1.error("error !")

We end up in an endless recursive loop here and the program crashes.

It seems LoggingHandler should require that a SDK LoggerProvider is passed in, and not an API LoggerProvider. ?

Right now if nothing is passed to the LoggingHandler (like in my code above), it can default to the ProxyLoggerProvider which is an API LoggerProvider and it causes that endless recursive call..

Also LoggingHandler expects it’s provider to provide a resource here, which the API LoggerProvider does not have..

Aaron also mentioned that he ran into this and can probably provide more context on what exactly the issues are here and how to fix things

Steps to Reproduce

See above..

Expected Result

See above.

Actual Result

See above..

Additional context

No response

Would you like to implement a fix?

Yes

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 in opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/init.py at LoggingHandler initialization and provider use, then compare it with opentelemetry-api/src/opentelemetry/_logs/_internal/init.py, including ProxyLoggerProvider and the recursive call site. Reproduce the provided handler setup and verify that initialization no longer permits the recursive loop or later missing-resource failure.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.