docs(python): Document enable_logs as deprecated, not a no-op - #19115
Merged
Conversation
Python SDK 2.68.1 restored enable_logs as a compatibility layer. When an integration leaves capture_sentry_logs unset, enable_logs=True turns automatic log capture back on for the logging and Loguru integrations, and an explicit capture_sentry_logs always wins. The docs still described the option as a no-op as of 2.68.0, and listed the capture_sentry_logs default as False rather than unset. Users on enable_logs were told their config had no effect when it does, and users debugging missing logs were pointed only at the new option. Add a precedence table for the two options, correct the integration option defaults to unset, and note that 2.68.0 alone had no effect. Refs getsentry/sentry-python#7237 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
inventarSarah
pushed a commit
that referenced
this pull request
Aug 26, 2026
## DESCRIBE YOUR PR Python SDK [2.68.1](https://github.com/getsentry/sentry-python/releases/tag/2.68.1) restored `enable_logs` as a deprecated compatibility layer ([sentry-python#7237](getsentry/sentry-python#7237)), walking back part of the removal documented in #19029. Our docs still describe the option as a no-op. Concretely, in 2.68.1 the `capture_sentry_logs` default changed from `False` to an internal sentinel, and the "`enable_logs` has no effect" warning was removed from `client.py`. So when an integration leaves `capture_sentry_logs` unset, `enable_logs=True` turns automatic log capture back on for the `logging` and Loguru integrations, while an explicit `capture_sentry_logs` always wins: | `enable_logs` | `capture_sentry_logs` | Automatic capture | | ----------------- | --------------------- | ----------------- | | not set / `False` | not set | off | | `True` | not set | on | | any | `True` | on | | any | `False` | off | Two user-facing consequences of the stale docs: users on `enable_logs=True` are told their config has no effect when it does, and users debugging missing logs are pointed only at the new option. - Rewrite the `enable_logs` entry in the Python options reference as **deprecated** rather than a no-op, with the precedence table above - Note that `2.68.0` alone had no effect, so anyone relying on the option upgrades to `2.68.1`+ - Correct the `capture_sentry_logs` default on both the `logging` and Loguru integration pages from `False` to unset, and explain the `enable_logs` fallback - Mention the deprecated path in both "Logs not appearing in Sentry" troubleshooting entries - Reword the level-threshold sentences that were conditioned on `capture_sentry_logs is True` Not included: `DjangoIntegration(failed_request_status_codes=...)` shipped in the same release ([sentry-python#7140](getsentry/sentry-python#7140)) and is undocumented, but it's an unrelated option — worth a separate PR. ## IS YOUR CHANGE URGENT? Help us prioritize incoming PRs by letting us know when the change needs to go live. Select exactly one option. For deadlines, replace `YYYY-MM-DD` with the due date. You can update this information later by editing the PR description. - [ ] Urgent deadline (GA date, etc.): YYYY-MM-DD - [ ] Other deadline: YYYY-MM-DD - [x] No deadline: Not urgent, can wait up to 1 week+ ## SLA - Teamwork makes the dream work, so please add a reviewer to your PRs. - Please give the docs team up to 1 week to review your PR unless you've supplied a deadline. Thanks in advance for your help! ## PRE-MERGE CHECKLIST _Make sure you've checked the following before merging your changes:_ - [ ] Checked Vercel preview for correctness, including links - [ ] PR was reviewed and approved by any necessary SMEs (subject matter experts) - [ ] PR was reviewed and approved by a member of the [Sentry docs team](https://github.com/orgs/getsentry/teams/docs) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DESCRIBE YOUR PR
Python SDK 2.68.1 restored
enable_logsas a deprecated compatibility layer (sentry-python#7237), walking back part of the removal documented in #19029. Our docs still describe the option as a no-op.Concretely, in 2.68.1 the
capture_sentry_logsdefault changed fromFalseto an internal sentinel, and the "enable_logshas no effect" warning was removed fromclient.py. So when an integration leavescapture_sentry_logsunset,enable_logs=Trueturns automatic log capture back on for theloggingand Loguru integrations, while an explicitcapture_sentry_logsalways wins:enable_logscapture_sentry_logsFalseTrueTrueFalseTwo user-facing consequences of the stale docs: users on
enable_logs=Trueare told their config has no effect when it does, and users debugging missing logs are pointed only at the new option.enable_logsentry in the Python options reference as deprecated rather than a no-op, with the precedence table above2.68.0alone had no effect, so anyone relying on the option upgrades to2.68.1+capture_sentry_logsdefault on both theloggingand Loguru integration pages fromFalseto unset, and explain theenable_logsfallbackcapture_sentry_logs is TrueNot included:
DjangoIntegration(failed_request_status_codes=...)shipped in the same release (sentry-python#7140) and is undocumented, but it's an unrelated option — worth a separate PR.IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
Select exactly one option. For deadlines, replace
YYYY-MM-DDwith the due date. You can update this information later by editing the PR description.SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes: