fix: pass sentry_logs_level only to sentry-sdk versions that accept it - #244
Merged
Merged
Conversation
This was referenced Sep 20, 2026
Closed
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
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.
Released in 1.8.0 and still in 1.9.0: every Sentry-enabled service on sentry-sdk 2.1 through 2.24
crashes at bootstrap.
sentry_instrument.pypassedsentry_logs_level=Noneunconditionally (added in #231). That parameterarrived in sentry-sdk 2.25.0, bisected against PyPI; the declared floor is
sentry-sdk>=2.1.Reproduced at the floor with a plain config, no test scaffolding:
The fix
A capability check computed once at import, rather than raising the floor to
>=2.25and dropping 24sentry-sdk releases:
This is not a workaround for an unsupported keyword. Below 2.25 there is no Sentry Logs feature at
all, so
SentryLogsHandlerdoes not exist and there is no wasted formatting to suppress. The saving#186 shipped is only available where the feature is, and omitting the keyword elsewhere is the
accurate thing to do, not a compromise.
Verified on both sides:
TypeError_breadcrumb_handler,_handler; no logs handler existsNone, so #186's saving still appliesCI would have caught this, one day later
scripts/floor_smoke.py freefails onmainwith the sameTypeErrorand passes with this change.It is only reached by the
lowest-directjob, which does not run on pull requests, so #231 neverexercised a floor. The daily cadence added in #233 would have opened a tracking issue at 06:00 UTC.
(Measuring that took two attempts:
uv pip install <path>is a copied install, not editable, soswapping the source file under a built venv proves nothing. The result above comes from reinstalling
each version.)
Test
One parametrized invariant over the capability flag: passed when the SDK accepts it, omitted when it
does not. It asserts through
_build_integrations()rather thansentry_sdk.init, so it does notdepend on SDK global state.
324 tests,
ruff,tyclean.Wants a
1.9.1immediately: the current release is broken for anyone not on a recent sentry-sdk.