Skip to content

fix(aws-lambda): Remove messaging.batch.message_count from the Lambda span - #8229

Merged
sentrivana merged 6 commits into
major/3.0from
junior/aws-lambda-span-no-batch-count
Nov 12, 2026
Merged

sentrivana merged 6 commits into
major/3.0from
junior/aws-lambda-span-no-batch-count

Conversation

@sentry-junior

@sentry-junior sentry-junior Bot commented Nov 9, 2026

Copy link
Copy Markdown
Contributor

Description

The Lambda span set messaging.batch.message_count to 1 for every event that isn't a list, and to len(event) for a top-level list. An SQS or SNS delivery is a dict with Records, so a batch of 10 messages reported 1. HTTP calls and direct invocations reported a batch they don't have.

This PR removes the attribute from the Lambda span. The count belongs on messaging spans, as in the OTel messaging conventions:

The JS SDK doesn't set it on the Lambda span either. The attribute was added in 3.0 (#7941) and never shipped in 2.x, so no released behavior changes.

Replaces #8219 (same commits). GitHub never ran CI on #8219.

Note for review: this is narrower than PY-3015, which asks to keep the attribute for SQS/SNS deliveries. @alexander-alderman-webb, please confirm that's OK.

Issues

  • resolves: PY-3015

via @dingsdax.

--

View Session [Sentry]

sentry-junior Bot and others added 4 commits November 9, 2026 07:10
…NS batches

The Lambda span set messaging.batch.message_count to 1 for every non-list
event and to len(event) for a top-level list. An SQS or SNS delivery is a
dict with Records, so a batch of 10 messages reported 1, and HTTP or
direct invocations reported a batch they don't have.

Set it only when all records come from SQS or SNS, to the number of
records.

Co-Authored-By: Johannes Daxböck <114897+dingsdax@users.noreply.github.com>
… span

Replace the SQS/SNS record counting with a plain removal. The count
belongs on messaging spans (boto3 receive and batch-send spans, and the
queue.process span for SQS/SNS triggers), as in the OTel messaging
conventions. The JS SDK doesn't set it on the Lambda span either.

The attribute was added in 3.0 and never shipped in 2.x.

Co-Authored-By: johdax <114897+dingsdax@users.noreply.github.com>
…event

Co-Authored-By: Johannes Daxböck <114897+dingsdax@users.noreply.github.com>
@linear-code

linear-code Bot commented Nov 9, 2026

Copy link
Copy Markdown

PY-3015

@github-actions

github-actions Bot commented Nov 9, 2026 •

Copy link
Copy Markdown
Contributor

Coverage Results 📊

✅ 58405 passed | ❌ 1 failed | ⏭️ 3071 skipped | Total: 61477 | Pass Rate: 95% | Execution Time: 155m 2s

❌ Failed Tests

test_cache_spans_decorator

File: tests.integrations.django.test_cache_module
Suite: py3.14-django-v6.1.3
Error: tests/integrations/django/test_cache_module.py:307: in test_cache_spans_decorator assert not spans[0]["attributes"]["cache.hit"] E assert not True

Stack Trace
tests/integrations/django/test_cache_module.py:307: in test_cache_spans_decorator
    assert not spans[0]["attributes"]["cache.hit"]
E   assert not True

✅ Patch coverage is 100.00% (no changed executable lines found; target 80%).
Project statement coverage is 90.30% (up 0.09 percentage points from base (df16ce5) to head (d306970)).

Files with missing lines (1)
File Coverage % Lines
sentry_sdk/integrations/aws_lambda/_handler.py 16.54% ⚠️ 106 Missing
Coverage diff
@@            Coverage Diff             @@
##        master     #8229       +/-##
==========================================
+ Coverage    90.21%    90.30%    +0.09%
==========================================
  Files          203       199        -4
  Tracked lines     27335     21824     -5511
  Branches     10246      7604     -2642
==========================================
- Hits         24660     19708     -4952
+ Misses        2675      2116      -559
+ Partials      1559      1255      -304

Generated by Coverage Action

sentrivana added a commit that referenced this pull request Nov 12, 2026
)

### Description

Since #8137, #8142, and #8145, boto3 puts `sentry-trace` in SQS and SNS
message attributes, but nothing reads it on the Lambda side. This PR is
the smallest change that closes the loop for SQS- and SNS-triggered
functions. The Lambda integration now reads `sentry-trace` from each
record and adds a `message_origin` link from the invocation span to each
distinct producer span. This matches what the boto3 `ReceiveMessage`
span already does. Messages never become the invocation's parent.

It reads:
- SQS records: `messageAttributes["sentry-trace"].stringValue`
- SNS records: `Sns.MessageAttributes["sentry-trace"].Value`
- SNS → SQS without raw message delivery: the SNS envelope in the SQS
`body`, the same as boto3 does

Links are deduplicated, because a batch send gives many messages the
same producer span, and capped at 128, OTel's default, because Lambda
can deliver up to 10,000 SQS messages at once.

**Scope.** This is intentionally kept separate from the stretch stack.
It doesn't add `faas.trigger` (#8222) or `queue.process` spans (#8223),
and it doesn't touch `messaging.batch.message_count` (#8229). The
invocation span is otherwise unchanged. Synchronous `Invoke` propagation
through `ClientContext` is #8221. That PR changes the `continue_trace`
call and this one only adds `links=`, so the two are independent.

The link-building code repeats boto3's `_message_link` in a Lambda-event
shape: Lambda records use `messageAttributes` / `stringValue` / `body`,
while the boto3 response uses `MessageAttributes` / `StringValue` /
`Body`. Importing from the boto3 integration would make `aws_lambda`
depend on botocore.

**Testing.** `test_producer_links` sends SQS, SNS, and SNS-to-SQS events
to `BasicOkSpanStreaming`. It asserts the segment span's `links` and
that the segment span has no parent. It passes in CI's Cloud (Lambda)
jobs, and `ruff` and `mypy sentry_sdk` pass. `codecov/patch` is red
because the Lambda tests run in `sam local` containers, so their
coverage isn't counted.

#### Issues
* Part of #8081

<!-- junior-request-attribution:start -->
via **webb**, @sentrivana.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC09M26BC6A1%3A1794211222.463239 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC09M26BC6A1%3A1794211222.463239)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC09M26BC6A1%3A1794211222.463239/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Alexander Webb <alexander.webb@sentry.io>
Co-authored-by: Ivana Kellyer <131587164+sentrivana@users.noreply.github.com>
@sentrivana
sentrivana marked this pull request as ready for review November 12, 2026 13:16
@sentrivana
sentrivana requested a review from a team as a code owner November 12, 2026 13:16
sentry-junior Bot added a commit that referenced this pull request Nov 12, 2026
Restores the batch count on the invocation span, as on major/3.0, so this
PR only adds faas.trigger.
@sentrivana

Copy link
Copy Markdown
Collaborator

@sentry-junior Why was this attribute added in the first place if it was wrong? Can you double-check that removing it is the right way to go?

@sentry-junior

sentry-junior Bot commented Nov 12, 2026

Copy link
Copy Markdown
Contributor Author

Checked again. Short version: it came from the old batch_size tag, and removing it from the invocation span is right. I also had one fact wrong in the description, which I've fixed.

Where it came from. batch_size goes back to #915 (2020). That change handles a handler that gets a top-level list (a manual batch Invoke). It used the first item for request data and set the batch_request / batch_size tags when the list had more than one item. When span streaming was added in #6498 (2.63.0, behind the trace_lifecycle experiment), that value was mapped to messaging.batch.message_count on the function span. #7941 kept it in 3.0. I was wrong before: it is in 2.x since 2.63.0, but only with span streaming on.

Why it's wrong on that span.

  • It counts list items, not messages. SQS, SNS, Kinesis and other event sources deliver a dict with Records, so a batch of 10 SQS messages reports 1. Every HTTP call or direct invoke also reports a batch of 1.
  • OTel's AWS Lambda conventions (SQS event) put the messaging attributes on a separate CONSUMER "process" span whose parent is the function's invocation span. They don't put them on the invocation span. messaging.batch.message_count is a messaging-span attribute.
  • JS sets it only on messaging spans (aws-sdk SQS spans, Cloudflare and Kafka consumers), never on the aws-serverless function span.

Where the count lives instead. boto3 send-batch and receive spans (#8137, #8142), and the queue.process span in #8223, which sets len(Records) for SQS/SNS triggers. So the count isn't lost for message triggers. It moves to the span where it means something.

The one behavior change: span-streaming users on 2.63+ who invoke with a top-level list lose this attribute in 3.0. If we want to keep that case, a better home would be the old batch_size tag or a Lambda-specific attribute, not a messaging attribute.

@sentrivana

Copy link
Copy Markdown
Collaborator

If this is a change from 2.x, also add it to MIGRATION_GUIDE.md

@sentrivana
sentrivana merged commit 08ebd25 into major/3.0 Nov 12, 2026
9 checks passed
@sentrivana
sentrivana deleted the junior/aws-lambda-span-no-batch-count branch November 12, 2026 13:26
sentrivana pushed a commit that referenced this pull request Nov 12, 2026
### Description

Sets `faas.trigger` on the Lambda span based on the shape of the
delivered event:
- `http`: API Gateway REST/HTTP, function URLs, ALB, CloudFront, AppSync
- `pubsub`: SQS, SNS, Kinesis, Kafka, MQ, SES, EventBridge
- `datasource`: S3, DynamoDB Streams, DocumentDB
- `timer`: EventBridge schedules
- `other`: anything else

The trigger is read from the event envelope, never from its payload.
`test_trigger` has one case per code path. Other event sources use the
same lookup table, so they have no extra cases.

This PR doesn't touch `messaging.batch.message_count`. That change is in
#8229.

This is Pablo's code from `pablo/aws-lambda-trigger`, without his batch
counting for the invocation span. It's the second of three stacked PRs
(#8221 → this → #8223).

#### Issues
* resolves: PY-3018 (`faas.trigger` part; the per-source attributes in
the issue aren't in this PR)
* Part of #8081

<!-- junior-request-attribution:start -->
via @dingsdax.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:slack%3AC0C9X9V5NMT%3A1793904671.980379 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379)
[[Sentry]](https://sentry.sentry.io/explore/conversations/slack%3AC0C9X9V5NMT%3A1793904671.980379/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: Pablo Deputter <pablo.deputter@sentry.io>
Co-authored-by: Pablo Deputter <71842639+pabloDeputter@users.noreply.github.com>
Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: Johannes Daxböck <114897+dingsdax@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants