Skip to content

feat(django): Add failed_request_status_codes - #7140

Merged
ericapisani merged 1 commit into
getsentry:masterfrom
mgaligniana:GH-3134-add-failed-request-status-code-for-django
Aug 13, 2026
Merged

feat(django): Add failed_request_status_codes#7140
ericapisani merged 1 commit into
getsentry:masterfrom
mgaligniana:GH-3134-add-failed-request-status-code-for-django

Conversation

@mgaligniana

@mgaligniana mgaligniana commented Aug 10, 2026 •
edited by ericapisani
Loading

Copy link
Copy Markdown
Contributor

Description

Hi! In this PR I've added failed_request_status_code to the Django integration

  • I used AI and reviewed the changes.

Since English isn't my first language, I tried to keep the comments as simple and clear as possible, so they're easy to understand even for beginners like me who don't know the full Sentry product. Feel free to make any changes or suggestions!

Issues

@mgaligniana
mgaligniana requested a review from a team as a code owner August 10, 2026 00:27
ericapisani
ericapisani requested changes Aug 10, 2026
View reviewed changes

@ericapisani ericapisani left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks for opening this PR @mgaligniana , we really appreciate you taking the time to do so!

Overall the changes are looking great. However, I don't think we can exclude the 5xx codes from the failed_request_status_codes (left a more detailed comment below) and we'll need to address that before we can merge.

Don't hesitate to reach out with any questions!

Comment thread sentry_sdk/integrations/django/__init__.py Outdated
Comment thread tests/integrations/django/test_basic.py
@mgaligniana
mgaligniana force-pushed the GH-3134-add-failed-request-status-code-for-django branch from 44db0ad to 805023b Compare August 12, 2026 12:43
@ericapisani
ericapisani merged commit 064542d into getsentry:master Aug 13, 2026
139 checks passed
@ericapisani

ericapisani commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

@mgaligniana Thanks so much again for your contribution! :shipit: 🚀

@mgaligniana

mgaligniana commented Aug 13, 2026

Copy link
Copy Markdown
Contributor Author

Wohoo!! Thanks to you for the review! Should I create a PR to sentry-docs or you handle that part?

@ericapisani Linear Code

ericapisani commented Aug 13, 2026

Copy link
Copy Markdown
Member

We'd love a PR if you have the time. If you don't though, don't sweat it, we can take care of it.

@sentry-release-bot sentry-release-bot Bot mentioned this pull request Aug 24, 2026
Closed
6 tasks
sentrivana pushed a commit that referenced this pull request Aug 25, 2026
@mgaligniana @sentrivana
feat(django): Add failed_request_status_codes (#7140)
b9151ea
@dingsdax dingsdax mentioned this pull request Aug 25, 2026
Merged
6 tasks
dingsdax added a commit to getsentry/sentry-docs that referenced this pull request Aug 25, 2026
@dingsdax @claude
docs(python): Document enable_logs as deprecated, not a no-op (#19115)
c00b521 
## 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>
@ericapisani ericapisani mentioned this pull request Aug 25, 2026
Merged
6 tasks
inventarSarah pushed a commit to getsentry/sentry-docs that referenced this pull request Aug 26, 2026
@dingsdax @claude @inventarSarah
docs(python): Document enable_logs as deprecated, not a no-op (#19115)
9e15dcd 
## 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>
ericapisani added a commit to getsentry/sentry-docs that referenced this pull request Aug 28, 2026
@ericapisani
docs(python): Document failed_request_status_codes option for Django (
4ad8ba7 
#19118)

<!-- Keep the urgency section so automation can prioritize this PR. You
may delete other sections you don't need. -->

## DESCRIBE YOUR PR

Add an `<SdkOption>` entry for `failed_request_status_codes` to the
Django integration page, matching the existing docs for this option in
the FastAPI, Starlette, aiohttp, litestar, and bottle integrations.

Related to changes introduced in
getsentry/sentry-python#7140

## 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)

## LEGAL BOILERPLATE

<!-- Sentry employees and contractors can delete or ignore this section.
-->

Look, I get it. The entity doing business as "Sentry" was incorporated
in the State of Delaware in 2015 as Functional Software, Inc. and is
gonna need some rights from me in order to utilize my contributions in
this here PR. So here's the deal: I retain all rights, title and
interest in and to my contributions, and by keeping this boilerplate
intact I confirm that Sentry can use, modify, copy, and redistribute my
contributions, under Sentry's choice of terms.

## EXTRA RESOURCES

- [Sentry Docs contributor guide](https://docs.sentry.io/contributing/)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@alexander-alderman-webb alexander-alderman-webb alexander-alderman-webb left review comments
@ericapisani ericapisani ericapisani approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@mgaligniana @ericapisani @alexander-alderman-webb