Comparing changes

…#8026) ### Description This fixes the `AI (3.10)` litellm flake. The test that fails changes from run to run. Recent example: `test_binary_content_encoding_mixed_content[False-False]`, which failed **7 times on master** between Sep 30 and Oct 13 ([job](https://github.com/getsentry/sentry-python/actions/runs/38237427670/job/114771446502)). Other failures were in `test_no_integration[False-False]` and `test_binary_content_encoding_image_url[True-False]`. All 10 litellm failures I looked at on master have the same cause: ``` /usr/lib/python3.10/threading.py:1011: in _bootstrap_inner _sys.settrace(_trace_hook) E RuntimeError: Cannot install a trace function while another trace function is being installed ``` **Root cause** - On CPython < 3.12, `_PyEval_SetTrace` uses a `static int reentrant` flag shared by the whole process. The flag stays set while audit hooks run ([python/cpython#98257](python/cpython#98257), fixed in 3.12). - `filelock` 3.30.0 through 4.0.2 registers a Python audit hook (`sys.addaudithook(_audit_fork_safety)`) when it is imported. The py3.10 litellm envs pin `filelock==3.32.4`, and `huggingface_hub` imports it during the first test. - pytest-cov calls `threading.settrace`, so every new thread calls `sys.settrace()` while it starts up. If the GIL switches while another thread is inside filelock's hook, the new thread's `settrace()` raises and the thread dies before it runs. - The tests create a new single-worker executor (`reset_litellm_executor`), and LiteLLM finishes the `gen_ai.chat` span in a success callback submitted to it. A dead worker means the callback never runs, so the test gets `len(chat_spans) == 0`. **Fix** `filelock` 4.0.3 fixed this upstream: it no longer registers the hook on CPython < 3.12 (`_SETTRACE_SURVIVES_AUDIT_HOOKS`). This PR adds a `py3.10,py3.11` rule, `filelock>=4.0.3`, to the litellm config, then regenerates `tox.ini` with `scripts/generate-test-files.sh --only litellm`. - Only the four `py3.10-litellm-*` blocks change; they now pin `filelock==4.1.0`. py3.12 and later are unaffected and unchanged. - Re-resolving those four blocks also moved other transitive pins, for example `anthropic` 1.0.0 → 1.13.0. - `releases.jsonl` is unchanged. `--only` would have pruned it, so I restored it. `package_dependencies.jsonl` only gains the 3 new resolution entries. No retries, sleeps, skipped tests or weaker assertions. **Reproduction:** getsentry/repro#60 It is a standalone script with no litellm and no pytest. On Python 3.10 with filelock 3.32.4, it lost 14 of 32,000 callbacks in one run, and 3 of 5 shorter runs (16,000 callbacks each) reproduced it. Under the same conditions it lost 0 of 32,000 with filelock 4.0.3, and 0 on Python 3.12. Original suite, run locally (`py3.10-litellm-v1.83.14`, with coverage): - With default settings: 0 of 20 runs failed. - With GIL switching set to happen more often (`sys.setswitchinterval(1e-6)` via a `-p` plugin; no test code changed): 4 of 20 runs hit the `RuntimeError`, and 3 of 20 failed. This is a **draft** until validation of the fix against both the repro and the original suite is posted here. Possible follow-up, not changed here: `py3.11-anthropic-v0.16.0` also pins `filelock==3.32.4`. #### Issues * resolves: getsentry#7014 * Linear: PY-2660  via Junior system actor `event`.    -- [View Junior Session](https://junior-prod.sentry.dev/conversations/agent-dispatch%3Adispatch_6df7374375b237816e130534b6439833) [[Sentry]](https://sentry.sentry.io/explore/conversations/agent-dispatch%3Adispatch_6df7374375b237816e130534b6439833/?project=4510944073809921)  Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>

…monitor (getsentry#8032) ### Description This fixes the flaky `tests/test_monitor.py::test_segment_uses_downsampled_rate` (`assert 0.25 == 0.5`, [job](https://github.com/getsentry/sentry-python/actions/runs/38393542918/job/115282966684)). Its siblings `test_transaction_uses_downsampled_rate` and `test_monitor_unhealthy` have the same race. **Root cause** These tests call `monitor.run()` by hand and assert exact `downsample_factor` values. They also set `monitor.interval = 0.1`. The first `monitor.is_healthy()` starts the monitor's background thread, which then calls `run()` every 0.1 s as well. On a slow runner (the failure was in Gevent 3.10, where the test took about 0.34 s), the thread runs an extra unhealthy check before the sampling decision. The factor goes from 1 to 2, so the sample rate is 0.25. **Fix** These tests now call `monitor.kill()` instead of shortening the interval. The thread `is_healthy()` starts then exits right away, so only the test's own `run()` calls change the factor. The assertions are unchanged, and there are no retries, sleeps or skips. SDK code is unchanged; this was a test bug. **Reproduction:** getsentry/repro#62 (sentry-sdk 2.72.0, Python 3.12). With random gaps of 0–0.2 s before sampling, the rate was wrong in 55 of 100 iterations. With gaps under 0.1 s it was 0 of 100, and with the background thread stopped it was 0 of 100. **Original tests, local runs** (`py3.14-common`). Each run covered the 3 affected tests. A test-only `-p` plugin added a random wait before `start_transaction` / `traces.start_span` to imitate a slow runner; no test or SDK code was changed by it. - `master`, no wait: 10 of 10 runs passed. The race doesn't show up locally on its own. - `master`, 0–200 ms wait: **11 of 15 runs failed**. `test_segment_uses_downsampled_rate` failed 6 times and `test_transaction_uses_downsampled_rate` 8 times. - This branch, 0–200 ms wait: **40 of 40 runs passed**. The baseline per-test failure rate was about 40%, so 9 clean runs would already give 99% confidence. - This branch, 0–500 ms wait: **20 of 20 runs passed**. - Regression checks: `tests/test_monitor.py`, `tests/tracing/test_sampling.py` and `tests/tracing/test_decorator.py` all passed (109 tests). `ruff` is clean. I haven't run the full common suite or the gevent setup locally; CI covers those. **Not changed here:** `test_trace_decorator_no_trx` also failed once, with leftover monitor logs (`downsampling with a factor of 10`). The likely cause is in `tests/conftest.py::sentry_init`: `inner()` assigns `client` without `nonlocal`, so the `client.close()` in teardown never runs. Monitor threads from earlier tests (with the 0.1 s interval) then keep running. I'll handle that separately, because closing every test client affects the whole suite. #### Issues * resolves: getsentry#8031  via **johdax**.    -- [View Junior Session](https://junior-prod.sentry.dev/conversations/agent-dispatch%3Adispatch_6df7374375b237816e130534b6439833) [[Sentry]](https://sentry.sentry.io/explore/conversations/agent-dispatch%3Adispatch_6df7374375b237816e130534b6439833/?project=4510944073809921)  Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com> Co-authored-by: Johannes Daxböck <[email protected]>

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/setup-java](https://redirect.github.com/actions/setup-java) ([changelog](https://redirect.github.com/actions/setup-java/compare/de7274f081f381c8f8158605e0321c36c376e2e6..b843ebf9b913146b38da2eaa7aeddf76074ae1ad)) | | digest | `de7274f` → `b843ebf` | | [actions/setup-java](https://redirect.github.com/actions/setup-java) ([changelog](https://redirect.github.com/actions/setup-java/compare/de7274f081f381c8f8158605e0321c36c376e2e6..b843ebf9b913146b38da2eaa7aeddf76074ae1ad)) | action | digest | `de7274f` → `b843ebf` | | [getsentry/coverage-action](https://redirect.github.com/getsentry/coverage-action) | | patch | `0.4.3` → `0.4.4` | | [getsentry/coverage-action](https://redirect.github.com/getsentry/coverage-action) | action | patch | `0.4.3` → `0.4.4` | | [java-jdk](https://adoptium.net) | uses-with | major | `21` → `25` | --- ### Release Notes <details> <summary>getsentry/coverage-action</summary> ### [`v0.4.4`](https://redirect.github.com/getsentry/coverage-action/blob/HEAD/CHANGELOG.md#044) [Compare Source](https://redirect.github.com/getsentry/coverage-action/compare/0.4.3...0.4.4) ##### New Features ✨ - (status) Add status-key input to namespace commit statuses by [@tyrantkhan](https://redirect.github.com/tyrantkhan) in [#118](https://redirect.github.com/getsentry/coverage-action/pull/118) ##### Internal Changes 🔧 - (dashboard) Freeze the artifact fixture clock by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#120](https://redirect.github.com/getsentry/coverage-action/pull/120) - (release) Default the merge target to main by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#121](https://redirect.github.com/getsentry/coverage-action/pull/121) - (status) Document and verify independent package statuses by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#119](https://redirect.github.com/getsentry/coverage-action/pull/119) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/getsentry/sentry-python).  --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [getsentry/craft](https://redirect.github.com/getsentry/craft) | action | minor | `2.34.1` → `2.35.0` | | [getsentry/craft](https://redirect.github.com/getsentry/craft) ([changelog](https://redirect.github.com/getsentry/craft/compare/3f2abdc5703191d12ef2cc013f792f1bd220f44d..7a7857552e2cdc08b502de96e6076849c01fba32)) | workflow | digest | `3f2abdc` → `7a78575` | | [java-jdk](https://adoptium.net) | uses-with | major | `21` → `25` | --- ### Release Notes <details> <summary>getsentry/craft</summary> ### [`v2.35.0`](https://redirect.github.com/getsentry/craft/blob/HEAD/CHANGELOG.md#2350) [Compare Source](https://redirect.github.com/getsentry/craft/compare/2.34.1...2.35.0) ##### New Features ✨ - (changelog) Add configurable AI summaries for CLI and Actions by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#902](https://redirect.github.com/getsentry/craft/pull/902) - (distribution) Release native Craft with install and setup tools by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#904](https://redirect.github.com/getsentry/craft/pull/904) ##### Bug Fixes 🐛 - (nuget) Pass --timeout to dotnet nuget push by [@sentry-junior](https://redirect.github.com/sentry-junior) in [#901](https://redirect.github.com/getsentry/craft/pull/901) ##### Internal Changes 🔧 - Add standalone Fossilize binaries and native smoke tests by [@MathurAditya724](https://redirect.github.com/MathurAditya724) in [#903](https://redirect.github.com/getsentry/craft/pull/903) </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/getsentry/sentry-python).  --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>

Fixes getsentry#8066

Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync. This adds `monitor_cron_jobs` to `ArqIntegration`, matching Celery's `monitor_beat_tasks`. When it's on, each `cron(...)` job sends check-ins with its schedule in the worker's timezone, so Sentry creates the monitor on the first run. The slug is the job name without arq's `cron:` prefix. It's off by default. ```python sentry_sdk.init( integrations=[ArqIntegration(monitor_cron_jobs=True, exclude_cron_jobs=["cleanup"])], ) ``` Jobs check in without a config when Crons can't express the schedule: a `second` other than 0, both `day` and `weekday` set, or a UTC offset that isn't a whole number of hours. Before arq 0.25, the config is only sent when the system timezone is UTC. Docs: getsentry/sentry-docs#20056

Update with more specific instructions on how to do things in order to increase the reviewability and maintainability of the produced changes. Also removed the Key Paths section as agents are quite adept at grepping and figuring out where what lives.

Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync. This adds `monitor_cron_jobs` to `RqIntegration` for recurring jobs from rq-scheduler's `scheduler.cron(...)` and `scheduler.schedule(..., interval=...)`. Only the worker needs the option, and it sends the cron string or interval as the monitor config. The slug is the job `id`, and jobs without one share a monitor named after the function's import path. It's off by default. ```python sentry_sdk.init( integrations=[RqIntegration(monitor_cron_jobs=True, exclude_cron_jobs=["cleanup"])], ) ``` Jobs aren't monitored when Sentry may read the cron string differently (6 fields, `@daily`, `MON`, both day fields set), the interval isn't whole minutes, the job has `repeat`, or the worker's local timezone isn't UTC. RQ's built-in `rq cron` scheduler isn't covered. The rq test envs now install `rq-scheduler` for RQ 2.x. Docs: getsentry/sentry-docs#20058 --------- Co-authored-by: Claude <[email protected]>

) Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync. This adds `monitor_periodic_tasks` to `HueyIntegration`, matching Celery's `monitor_beat_tasks`. When it's on, each `@huey.periodic_task` run sends check-ins with its `crontab(...)` schedule in UTC, so Sentry creates the monitor on the first run. The slug is the task name. It's off by default, and regular tasks are unaffected. ```python sentry_sdk.init( integrations=[HueyIntegration(monitor_periodic_tasks=True, exclude_periodic_tasks=["cleanup"])], ) ``` Tasks aren't monitored when they use a custom `validate_datetime`, restrict both `day` and `day_of_week`, or run on a Huey instance with `utc=False`. Docs: getsentry/sentry-docs#20057 --------- Co-authored-by: Claude <[email protected]>

…ry#8098) Part of a series adding automatic Crons monitoring for the most-used job schedulers in each SDK. Check-ins for a monitor that doesn't exist yet are dropped, so today each monitor has to be created by hand with its schedule copied from the code. Sending the job's schedule as the monitor config lets Sentry create the monitor and keep it in sync. This is a quick fix to keep the arq integration behaviour in line with how other integrations work. Sorry for the churn! Follow-up to getsentry#8051. Cron jobs whose schedule Crons can't express are no longer monitored, instead of checking in without a config. This matches Celery beat, and the Huey and RQ integrations from getsentry#8052 and getsentry#8053. Docs: getsentry/sentry-docs#20056 Co-authored-by: Claude <[email protected]>

### Description Fixes Celery beat interval schedules being rounded down. A 90-minute schedule was sent as "1 hour" and a 36-hour one as "1 day", so Sentry expected runs that never happened and raised false missed-check-in alerts. Intervals now use the largest unit that divides them evenly (90 minutes stays 90 minutes). Intervals that aren't a whole number of minutes, such as 90 seconds, send no monitor config and log a warning, like sub-minute intervals already do. Existing monitors with uneven intervals get the correct interval on their next check-in. For intervals that now send no config, new monitors aren't auto-created and existing ones keep their current schedule. ### Testing Unit tests for the interval conversion and the beat monitor config. --------- Co-authored-by: Claude <[email protected]>

### Description That version [is vulnerable](https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/#payload-2-the-backdoor-in-sitecustomizepy) so it would be great to exclude it from extras. To be honest, we don't use that extra but since we use poetry, the litellm version range shows up in our poetry.lock and it doesn't look good for our security team. Thanks! #### Issues * resolves: getsentry#8103 * resolves: PY-3035 #### Reminders - Please add tests to validate your changes, and lint your code using `uv run ruff`. - Add GH Issue ID _&_ Linear ID (if applicable) - PR title should use [conventional commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type) style (`feat:`, `fix:`, `ref:`, `meta:`) - For external contributors: [CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md), [Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord community](https://discord.gg/Ww9hbqr) Co-authored-by: Jonny <[email protected]>

…#8114) Bumps [certifi](https://github.com/certifi/python-certifi) from 2026.7.22 to 2026.10.19. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914"><code>662df63</code></a> Restore unaffected emSign roots (<a href="https://redirect.github.com/certifi/python-certifi/issues/439">#439</a>) (<a href="https://redirect.github.com/certifi/python-certifi/issues/440">#440</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8"><code>5cb238c</code></a> Remove emsign (<a href="https://redirect.github.com/certifi/python-certifi/issues/437">#437</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/69494a764d0a08f90838d53d4b0fefd3e84045d6"><code>69494a7</code></a> Bump actions/download-artifact from 8.0.1 to 8.0.2 (<a href="https://redirect.github.com/certifi/python-certifi/issues/436">#436</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/029c7b0913d79e2efb73a216fc5c5e13ef958536"><code>029c7b0</code></a> Bump actions/upload-artifact from 7.0.1 to 7.0.2 (<a href="https://redirect.github.com/certifi/python-certifi/issues/435">#435</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/9d0a8f1f3a0d6b2e38d5773db7afe1a37e4527b6"><code>9d0a8f1</code></a> Add support for Python 3.15 (<a href="https://redirect.github.com/certifi/python-certifi/issues/432">#432</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/db472abf0a37067cb4488f036f4c19adf6b6ec3c"><code>db472ab</code></a> Bump pypa/gh-action-pypi-publish from 1.14.1 to 1.14.2 (<a href="https://redirect.github.com/certifi/python-certifi/issues/431">#431</a>)</li> <li>See full diff in <a href="https://github.com/certifi/python-certifi/compare/2026.07.22...2026.10.19">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=certifi&package-manager=uv&previous-version=2026.7.22&new-version=2026.10.19)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/getsentry/sentry-python/network/alerts). </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ng `sentry-` entries (getsentry#8116)

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Uh oh!

Commits on Oct 14, 2026

Commits on Oct 15, 2026

Commits on Oct 16, 2026

Commits on Oct 20, 2026

Commits on Oct 21, 2026

Commits on Oct 22, 2026

Commits on Oct 23, 2026

This comparison is taking too long to generate.

Uh oh!