| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
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 @@
## 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 |
Sorry, something went wrong.
…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.
## 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>
## 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>
| Back | FazBrowse Home | New Git URL |
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.