fix(logs): Don't stop sending auto-collected logs when enable_logs=True - #7237
Merged
Merged
Conversation
Contributor
Codecov Results 📊✅ 113725 passed | ⏭️ 6732 skipped | Total: 120457 | Pass Rate: 94.41% | Execution Time: 413m 44s 📊 Comparison with Base Branch
➖ Removed Tests (1)View removed tests
All tests are passing successfully. ✅ Patch coverage is 100.00%. Project has 2481 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 90.20% 90.24% +0.04%
==========================================
Files 193 193 —
Lines 25421 25433 +12
Branches 9340 9346 +6
==========================================
+ Hits 22932 22952 +20
- Misses 2489 2481 -8
- Partials 1438 1437 -1Generated by Codecov Action |
alexander-alderman-webb
approved these changes
Aug 24, 2026
6 tasks
sentrivana
added a commit
that referenced
this pull request
Aug 25, 2026
…rue` (#7237) Easing the transition to an `enable_logs`-free world. Folks who currently have `enable_logs=True` can use our logging API, and they'll have auto-collection of logs from the stdlib logging and Loguru integrations on by default. In the last release, since we made `enable_logs` no-op, they'd lose their auto-collected logs until they'd explicitly opted in via the new integration options. Make the transition easier for users who have `enable_logs=True` now: consider the option in both the Logging and Loguru integrations and make them auto-collect unless explicitly opted-out via one of the integration-level options.
6 tasks
dingsdax
added a commit
to getsentry/sentry-docs
that referenced
this pull request
Aug 25, 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>
inventarSarah
pushed a commit
to getsentry/sentry-docs
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.
Easing the transition to an
enable_logs-free world.Folks who currently have
enable_logs=Truecan use our logging API, and they'll have auto-collection of logs from the stdlib logging and Loguru integrations on by default.In the last release, since we made
enable_logsno-op, they'd lose their auto-collected logs until they'd explicitly opted in via the new integration options.Make the transition easier for users who have
enable_logs=Truenow: consider the option in both the Logging and Loguru integrations and make them auto-collect unless explicitly opted-out via one of the integration-level options.