Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
DylanRussell opened this issue May 14, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@DylanRussell
Copy link
Contributor

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

@aabmass
Copy link
Member

aabmass commented May 14, 2025

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..

I think it does assume this right now but it should not. Also see #4330

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

I think the underlying problem is that the LogRecord API should not have a resource. (the exporting format that is part of LogData is something different)

@DylanRussell
Copy link
Contributor Author

Ok so you're saying LoggingHandler should accept either a SDK / API LoggerProvider and then return either a SDK / API LogRecord ?

Yeah I see resource is the one field being populated that's in the SDK LogRecord and not in the API LogRecord

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants