open-telemetry / open-telemetry/opentelemetry-python

LogRecord deprecation warning with no replacement

Open
#4,783 6 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

Hello, our users are seeing hundreds of these warnings in their logs:

2025-10-21 09:10:49.495 UTC - [INFO] - /foo/bar/baz.py:52: LogDeprecatedInitWarning: LogRecord will be removed in 1.39.0 and replaced by ReadWriteLogRecord and ReadableLogRecord
2025-10-21 09:10:49.495 UTC - [INFO] -   return LogRecord(

We're already on 1.38, and neither ReadWriteLogRecord or ReadableLogRecord appear to exist in this repository. (Furthermore, it looks like the warning is only meant to fire once? But maybe that's something going wrong on our side.)

Apologies if I've missed something, but how are users meant to resolve this? I don't feel very professional even silencing the warnings for now, because 1.39 is the next minor version so there's no logical point for me to surface an internal warning based on a check the otel version - I'd have only allowed the supresssion until 1.38. As well as this, are we striking the right balance with warning noise? It seems fairly non-standard to deprecate something before the replacement is available.

Thanks in advance,
Tom

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 opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/init.py, especially the LogDeprecatedInitWarning path linked in the issue. Check why LogRecord is deprecated in version 1.38 while ReadWriteLogRecord and ReadableLogRecord are unavailable, and verify the warning's once-only behavior. Done means the supported replacement or resolution is available and the warning accurately guides users.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.