Skip to content

Logging API accepts optional Context with priority over trace_id etc, and LoggingHandler passes current Context #4597

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
wants to merge 16 commits into
base: main
Choose a base branch
from

Conversation

tammy-baylis-swi
Copy link
Contributor

@tammy-baylis-swi tammy-baylis-swi commented May 22, 2025

Description

  1. Updates Logging API and SDK to accept an additional, optional otel Context at LogRecord init.
  2. Adds order-of-precedence so that, if provided Context includes a valid current span, its span information will be used instead of any trace_id, span_id, trace_flags provided at init.
  3. LogRecord's to_json does a serialization of what it can in Context (e.g. string, int) then casts to string for other values (e.g. Span). Removed in 73e7b39 as discussed with Python SIG.
  4. LoggingHandler's _translate inits LogRecord with current context. Logging SDK (LogRecord init) defaults to current context in 676d9ff, as discussed with Python SIG.

Let me know if too many changes for one PR and I can break it up or remove anything out of scope.

Fixes #4328

Replaces #4584

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Added unit test coverage
  • Installed SDK changes into my vendor's distro and logs export ok

Does This PR Require a Contrib Repo Change?

  • Yes. - Link to PR:
  • No.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added
  • Documentation has been updated

@tammy-baylis-swi tammy-baylis-swi changed the title Logs API/SDK accepts additional, optional Context Logging API accepts optional Context with priority over trace_id etc, and LoggingHandler passes current Context May 24, 2025
@@ -186,10 +189,22 @@ def __init__(
attributes: _ExtendedAttributes | None = None,
limits: LogLimits | None = _UnsetLogLimits,
):
# Prioritizes context over trace_id / span_id / trace_flags.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to maybe be more aggressive here since Logs are not stable and I foresee more breaking changes. Can we just deprecated these off the bat and log a warning if they're passed? We can then remove them before stable release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if using a deprecated overload to signal to users would work

@overload
@deprecated
def __init__(
  self,
  trace_id: int | None = None,
  span_id: int | None,
  trace_flags: int | None,
  **kwargs
): ...

Might be a little tricky but should be possible

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are not using warnings.deprecated in the codebase but I think it can works

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @deprecated decorator isn't available Python < 3.13 , but I'll try that approach!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created our own @deprecated decorator and set up an overload in 676d9ff. An alternative could be to introduce Deprecated as an additional dependency. Thoughts? 🙂

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call @emdneto ! Changed in bb92b7e

)
self.assertIsNotNone(log_record)
self.assertEqual(
log_record.trace_id, INVALID_SPAN_CONTEXT.trace_id
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this pass even without mock_context? Maybe we could set a real specific span in context to get more signal

span_context = SpanContext(
    trace_id=trace_id,
    span_id=span_id,
    ...,
)
with use_span(NonRecordingSpan(span_context)):
  ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, no mock_context needed for this test; removed in a0c817c.

For real span, does test_log_record_trace_correlation further down look ok?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Event API should accept Context instead of specific trace_id, span_id, trace_flags
3 participants