fix(deps): exclude sentry-sdk 2.69.0, which corrupts SigV4-signed headers - #263
Merged
Merged
Conversation
lesnik512
force-pushed
the
fix/sentry-2690-exclusion
branch
from
September 27, 2026 17:55
6ae710e to
9b9480d
Compare
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.
sentry-sdk 2.69.0 breaks every AWS call made through aiobotocore while a Sentry transaction is
active. Nothing in our metadata stops a user resolving onto it.
The bug
getsentry/sentry-python#7050, released in 2.69.0, moved boto3 trace propagation into botocore's
before-signevent, sosentry-traceandbaggageare set before SigV4 signing and land inSignedHeaders. The same PR taught thestdlibclient to leave signed propagation headers alone,but not the aiohttp client.
AioHttpIntegration.on_request_startstill overwritessentry-traceand appends to
baggageafter signing, so the bytes sent no longer match the bytes signed and theservice answers
SignatureDoesNotMatch.Both integrations auto-enable, and
Boto3Integrationkeys off botocore, not boto3, soinstalling aiobotocore alone turns on both. Sync boto3 is unaffected, and the failure only appears
while a transaction is open, which makes it look intermittent.
Upstream: getsentry/sentry-python#7426, fixed by getsentry/sentry-python#7427, released in 2.69.1
on 2026-09-08. 2.69.0 is the only affected release.
Why an exclusion rather than a floor raise
!=2.69.0removes the broken release and nothing else. Raising the floor to>=2.69.1would alsoclose a second variant, where anything else signs a
baggageheader before sentry sees the request(ddtrace >= 4.12 per getsentry/sentry-python#7050), which affects every version below 2.69.1. That
variant rests on one upstream description rather than a report against this project, and the raise
would cost 68 minor versions of SDK support, so it is not worth it here.
The tradeoff to note: this is library metadata, so it binds every consumer, and an app pinning
2.69.0 for unrelated reasons would now conflict. Excluding a single known-broken release with a
one-patch fix available is the narrowest form that guard can take.
The exclusion goes on all three marker lines. 2.69.0 sits above every declared floor
(
>=2.1,>=2.11,>=2.59), so it was reachable on every supported interpreter.Mitigations for users who cannot upgrade
Through
sentry_additional_params, in decreasing order of how much they keep:trace_propagation_targetsexcluding the AWS endpoints, which keeps spans everywhere andpropagation everywhere else. Works back to 2.1.
disabled_integrations=[AioHttpIntegration()], which loses all aiohttp client spans andpropagation, not only for AWS. Needs 2.11, where the option was added.
Passing
AioHttpIntegration()explicitly insentry_integrationsdoes not help: the explicitinstance installs the same client hook.
Verified
Resolution, on this checkout, capping sentry-sdk to force the broken release into range:
<2.69.1<2.70--resolution lowest-directThe floors are untouched, which the last row shows:
lowest-directstill picks the declared floorfor the interpreter (2.59.0 on 3.14 here).
eof-fixer --check,ruff format --check,ruff check --no-fixandty checkclean.pytest: 331 passed.mkdocs build --strictpasses.