You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: add support for event bridge DSM context extraction (#836)
* feat: add support for event bridge DSM context extraction
* chore: update processing of eventbridge DSM
* refactor: avoid extra allocation in eventbridge sqs parsing
* fix: require eventbridge envelope for sqs extraction
* fix: detect sqs carriers per record in eventbridge batches
* fix: use public dsm checkpoint for eventbridge
* chore: update to handle new public DSM API
* fix: extract SNS dsm context in mixed eventbridge/SNS sqs batches
When EventBridge and SNS are both routed to the same SQS queue and their
messages are batched into a single event payload, the SNS DSM context was
dropped.
_dsm_set_eventbridge_sqs_batch_checkpoints classifies every record in the
batch and falls back to _extract_sqs_record_message_attribute_context for
non-EventBridge records. That helper only read record.messageAttributes and
never unwrapped an SNS notification carried in the SQS body (an SNS => SQS
subscription without raw message delivery), so the SNS carrier resolved to
None. Because the batch contained an EventBridge delivery, dsm_handled was
True for the whole batch and the SNS-aware fallback path further down in
extract_context_from_sqs_or_sns_event_or_context never ran.
Teach the helper to unwrap the SNS envelope the same way the main SQS/SNS
extraction path already does, so each record in a mixed batch is classified
correctly regardless of whether it is a direct SQS send or an SNS delivery.
The shared attribute decoding and envelope detection are factored out into
_decode_dd_message_attribute and _parse_sns_notification_from_sqs_body.
* chore: bump lambda layer size limit for ddtrace 4.15.x
The zipped layer size check started failing at 9273 kb against the 9231 kb
limit. This is unrelated to any source change in this branch: the ddtrace
cp311 manylinux x86_64 wheel grew ~470 kb in 4.15.0 (8.87 MB in 4.14.2 ->
9.33 MB in 4.15.0), and pyproject.toml pins ddtrace ">=4.1.1,<5,!=4.6.*"
with no upper bound inside 4.x, so CI resolves to the newest 4.15.x.
Raise MAX_LAYER_COMPRESSED_SIZE_KB from 9*1024+15 (9231 KB) to 9*1024+128
(9344 KB), which clears the observed 9273 kb with ~71 kb of headroom while
keeping the guardrail tight enough to catch further growth. x86_64 is the
larger of the two published arches (~245 kb above aarch64), so the failing
cp311 x86_64 job is the worst case across the build matrix.
The uncompressed limit is unchanged.
* chore: update README with new flag
* fix: handle msg_attributes being empty object
Copy file name to clipboardExpand all lines: README.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -30,6 +30,7 @@ Besides the environment variables supported by dd-trace-py, the datadog-lambda-p
30
30
| DD_CAPTURE_LAMBDA_PAYLOAD |[Captures incoming and outgoing AWS Lambda payloads][1] in the Datadog APM spans for Lambda invocations. |`false`|
31
31
| DD_CAPTURE_LAMBDA_PAYLOAD_MAX_DEPTH | Determines the level of detail captured from AWS Lambda payloads, which are then assigned as tags for the `aws.lambda` span. It specifies the nesting depth of the JSON payload structure to process. Once the specified maximum depth is reached, the tag's value is set to the stringified value of any nested elements beyond this level. <br> For example, given the input payload: <pre>{<br> "lv1" : {<br> "lv2": {<br> "lv3": "val"<br> }<br> }<br>}</pre> If the depth is set to `2`, the resulting tag's key is set to `function.request.lv1.lv2` and the value is `{\"lv3\": \"val\"}`. <br> If the depth is set to `0`, the resulting tag's key is set to `function.request` and value is `{\"lv1\":{\"lv2\":{\"lv3\": \"val\"}}}`|`10`|
32
32
| DD_EXCEPTION_REPLAY_ENABLED | When set to `true`, the Lambda will run with Error Tracking Exception Replay enabled, capturing local variables. |`false`|
33
+
| DD_DSM_EXCHANGE_NAME | If you are using Datadog Data Streams Monitoring and propagating context through Amazon Event Bridge, this variable specifies the name of the EventBridge EventBus. The name of the bus is *not* passed through in the event payload and therefore cannot be automatically inferred at consume time. |`false`|
0 commit comments