Skip to content

Conversation

Copy link

Copilot AI commented Nov 27, 2025

Description

Documents two critical behaviors of LoggingHandler that users must understand:

  1. Root logger attachment: Handler attaches to root logger, so child loggers must have propagate=True (default) for logs to be exported
  2. dictConfig interaction: logging.config.dictConfig() may clear root logger handlers, removing the OTel handler

Changes:

  • docs/examples/logs/README.rst: Added "Important Usage Notes" section with examples
  • docs/examples/logs/example.py: Added inline comments explaining propagation behavior
  • opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py: Updated LoggingHandler docstring

Example for dictConfig preservation:

# Save handlers before dictConfig
root_handlers = logging.root.handlers[:]

logging.config.dictConfig(your_config)

# Restore OTel handler if removed
for handler in root_handlers:
    if isinstance(handler, LoggingHandler) and handler not in logging.root.handlers:
        logging.root.addHandler(handler)

Type of change

  • This change requires a documentation update

How Has This Been Tested?

  • tox -e ruff - linting and RST validation pass
  • tox -e opentelemetry-sdk - SDK tests pass

Does This PR Require a Contrib Repo Change?

  • No.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added (N/A - docs only)
  • Documentation has been updated
Original prompt

Follow these instructions exactly and produce clear, verifiable outputs. The repository contains a file named CURRENT_ISSUE.md (case-insensitive: current_issue.md). That file describes the issue you must fix. Your mission is to:

  1. Read the current_issue.md and fully understand the reported bug, failing test, or feature deficit. If the issue references specific files, tests, or behaviors, open and inspect those files. Assume you have read access to the repository working tree.
  2. Design and implement a minimal, well-tested fix that resolves the issue while preserving intended behavior. If the fix requires changing multiple files, make coherent, focused commits.
  3. Run the project's automated tests and linters locally. Use the project's recommended test command (search package.json, pyproject.toml, tox.ini, Makefile, or CONTRIBUTING.md). If no explicit command exists, use the conventional command for the language (e.g., pytest for Python). Ensure all tests pass before finishing.
  4. Update or add documentation so that the repository README, relevant module docstrings, and any user-facing docs clearly describe the change and how to use the fixed behavior.
  5. Create a file named fix_changelog.md at the repository root. In it, explain:
    • The problem (concise).
    • What changed (files, functions, configuration).
    • Why the change was made (root cause).
    • Tests added or updated.
    • Any backward compatibility considerations and migration steps if applicable.
  6. Use the repository's pull_request_template.md located in .github/pull_request_template.md to generate a completed pull_request.md. Fill the template thoroughly: brief summary, testing steps performed, review notes, changelog cross-reference, and any security or performance considerations.
  7. Follow repository contribution rules. Locate CONTRIBUTING.md (or docs/CONTRIBUTING.md). Respect branch naming conventions, commit message style, code style, and test coverage requirements specified. If the CONTRIBUTING document requires a specific header in commits, include it.
  8. Use a clear branch name: fix/current-issue- or following repository convention. Commit in small logical steps with descriptive messages. Create at least one commit that contains the actual fix and one commit that contains documentation and changelog updates.
  9. Provide a final patch summary in a file named fix_summary.txt at the repository root listing:
    • Files changed (with short diffs or descriptions).
    • Commands you ran to test and lint.
    • Test results (pass/fail and brief output).
    • Any remaining risks or follow-ups.
  10. If the repository has a CI configuration (e.g., .github/workflows, .gitlab-ci.yml), ensure CI-related files are not accidentally broken. If the fix requires CI changes (e.g., to add a new test runner or environment variable), include them and document why.
  11. Be conservative: prefer minimal, well-tested, readable changes over large refactors. Add comments explaining non-obvious behavior. Include type hints or types where appropriate.
    Acceptance criteria:
  • All tests pass locally and reported in fix_summary.txt.
  • fix_changelog.md clearly explains the fix.
  • pull_request.md is generated from the PR template and filled completely.
  • Documentation updated to avoid regressions.
  • Changes follow CONTRIBUTING.md rules.
    Deliverables (files to create/update):
  • Modified source files implementing the fix.
  • Updated tests or new tests.
  • Updated documentation files and README if relevant.
  • fix_changelog.md
  • pull_request.md (generated from pull_request_template.md)
  • fix_summary.txt
  • Git commits on a branch named per contributing conventions.
    Notes and constraints:
  • Do not introduce heavy external dependencies. Prefer standard libraries or existing project dependencies.
  • If the issue touches security-sensitive code, document the security reasoning in pull_request.md and fix_changelog.md.
  • If you cannot determine the correct behavior from current_issue.md, make a best-effort safe change and document assumptions and rationale in fix_summary.txt and pull_request.md.
  • If the repository uses multiple languages or services, limit changes to the minimum scope affecting current_issue.md.
  • When running tests, capture output (stdout/stderr) in fix_summary.txt.
  • The final pull_request.md should be human-readable and ready to paste into the repository.
    Use clear, conventional commit messages (feat/fix/docs/tests/chore) with a concise subject line limited to 72 characters, and a body explaining the rationale. If applicable, add or update type annotations and static type checks (mypy, typecheck) only where straightforward. When modifying public APIs, include deprecation notes for old behaviors and document replacement patterns. If new configuration options are introduced, validate inputs and provide sensible defaults and migration examples.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI and others added 3 commits November 27, 2025 14:04
Add important documentation about root logger instrumentation:
- Child loggers must have propagate=True for logs to be exported
- Handler preservation when using logging.config.dictConfig()

Updated files:
- docs/examples/logs/README.rst: Added Important Usage Notes section
- docs/examples/logs/example.py: Added explanatory comments
- opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py: Updated LoggingHandler docstring

Co-authored-by: BrianPetkovsek <16124109+BrianPetkovsek@users.noreply.github.com>
- Simplify nested if statements in README.rst example
- Rename variable 'h' to 'handler' for clarity in docstring example

Co-authored-by: BrianPetkovsek <16124109+BrianPetkovsek@users.noreply.github.com>
Co-authored-by: BrianPetkovsek <16124109+BrianPetkovsek@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix issue described in CURRENT_ISSUE.md docs: Document LoggingHandler root logger behavior and dictConfig usage Nov 27, 2025
Copilot AI requested a review from BrianPetkovsek November 27, 2025 14:09
Copilot finished work on behalf of BrianPetkovsek November 27, 2025 14:09
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.

2 participants