fix(boto3): Fix botocore SigV4 failures caused by post-sign trace propagation

[pabloDeputter]

Description

Summary of issue

• pre-4.12.0 ddtrace basically behaved like Sentry before: propagation headers were added by the HTTP client after botocore already had calculate the SigV4 signature. So baggage was not included in SignedHeaders. Any later modifications to the value did not invalidate the request.
• 4.12.0 moves the header injection to botocore's before-sign event. It adds baggage, ... and x-datadog-* before signing. Any later modifications to the value DO invalidate the request, thus later HTTP-client injection is suppressed to avoid duplicate headers.
• How failure happens:
  1. incoming FastAPI request contains Sentry or other W3C baggage
  2. datadog extracts that baggage into its active context
  3. boto3 request is created
  4. datadog’s before-sign handler writes the baggage to the AWS request
  5. botocore includes baggage in the SigV4 signature
  6. sentry’s httplib runs afterwards and updates or adds another baggage value
  7. AWS receives a different baggage value from the one that was signed. Because request was "tampered" with after signing, AWS rejects the request with 403 Forbidden or SignatureDoesNotMatch.

Changes

• inject sentry propagation through before-sign handler, so final baggage and sentry-trace values are created before SigV4 signing.
• existing third-party baggage is merged into one header.
• http.client propagation is delayed until endheaders(), when the complete request headers and SigV4 SignedHeaders are available. Existing baggage header is never mutated after it already was signed.
• propagation is skipped for presigned requests, since adding headers could require a future caller to reproduce these exact headers.

Issues

Resolves: #7031 & PY-2667

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 style (feat:, fix:, ref:, meta:)
• For external contributors: CONTRIBUTING.md, Sentry SDK development docs, Discord community

[github-actions]

Codecov Results 📊

✅ 99283 passed | ⏭️ 6494 skipped | Total: 105777 | Pass Rate: 93.86% | Execution Time: 340m 44s

📊 Comparison with Base Branch

Metric	Change
Total Tests	📈 +140
Passed Tests	📈 +126
Failed Tests	📉 -1
Skipped Tests	📈 +15

➖ Removed Tests (1)

View removed tests

• test_continuous_profiler_auto_start_and_stop_sampled_span_streaming[non-experiment-thread]
  • File: tests.profiler.test_continuous_profiler

All tests are passing successfully.

✅ Patch coverage is 94.81%. Project has 2503 uncovered lines.
✅ Project coverage is 89.99%. Comparing base (base) to head (head).

Files with missing lines (2)

File	Patch %	Lines
sentry_sdk/integrations/stdlib.py	94.12%	⚠️ 3 Missing and 4 partials
sentry_sdk/integrations/boto3.py	96.15%	⚠️ 1 Missing and 1 partials

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    89.99%    89.99%        —%
==========================================
  Files          193       193         —
  Lines        24946     25016       +70
  Branches      9000      9034       +34
==========================================
+ Hits         22451     22513       +62
- Misses        2495      2503        +8
- Partials      1435      1437        +2

---

Generated by Codecov Action

[alexander-alderman-webb]

Does calling sentry_sdk.get_current_scope().iter_trace_propagation_headers() here instead of in putrequest() work?
It would be best to avoid stashing stuff on the HTTPConnection instance if we can help it.

[pabloDeputter]

Good suggestion :) header generation is moved into endheaders() instead of being stored on the connection.

[sentry-warden]

SigV4 parser aborts on first non-AWS Authorization header

_aws_sigv4_signed_headers returns an empty set on the first Authorization header that does not start with the expected AWS schemes, so a later valid SigV4 header is never inspected and trace headers can be injected, invalidating the signature.

Evidence

• _aws_sigv4_signed_headers iterates buffer lines looking for Authorization headers.
• When it finds an Authorization line whose value does not start with AWS4-HMAC-SHA256 or AWS4-ECDSA-P256-SHA256, it returns set() immediately.
• Because the loop does not continue, any valid SigV4 header later in buffer is never parsed.
• This causes the downstream endheaders logic to see an empty signed_headers set and inject trace headers that break the AWS signature.

_{Identified by Warden · find-bugs · UD9-DXE}

[pabloDeputter]

There shouldn't be multiple Authorization headers, nevertheless replaced return set() with continue.