[SLES-2961] fix(traces): extract Binary _datadog attribute from SQS records - #1314
[SLES-2961] fix(traces): extract Binary _datadog attribute from SQS records#1314litianningdatadog wants to merge 3 commits into
Conversation
…ecords SqsRecord::get_carrier() only checked string_value on the _datadog message attribute, so a Binary-typed attribute (as delivered by SNS raw message delivery) was silently ignored and the trace context was never extracted. Branch on data_type instead, base64-decoding the Binary case, matching the existing SnsRecord::get_carrier() behavior.
There was a problem hiding this comment.
Pull request overview
Fixes Datadog trace context propagation for SNS→SQS→Lambda when the _datadog message attribute is delivered as a Binary SQS message attribute (e.g., via SNS raw message delivery), by decoding and parsing the carrier rather than falling back to SNS-envelope parsing.
Changes:
- Update
SqsRecord::get_carrier()to branch on SQS message attributedataTypeand base64-decode Binary_datadogvalues before parsing carrier JSON. - Add a new SQS Binary-attribute fixture plus a unit test to reproduce the issue and validate the fix.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
bottlecap/src/lifecycle/invocation/triggers/sqs_event.rs |
Adds Binary dataType handling for _datadog carrier extraction and a corresponding unit test. |
bottlecap/tests/payloads/sqs_event_binary.json |
Adds a fixture representing an SQS record with _datadog as a Binary message attribute. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a134be5094
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Match "String"/"Binary" on ma.data_type via starts_with instead of exact equality, since SQS/SNS dataType values may carry a custom label suffix (e.g. "String.foo"). Exact matching silently dropped the carrier for any custom-labeled attribute, regressing behavior that worked before this PR (previously stringValue was used whenever present, regardless of dataType).
https://datadoghq.atlassian.net/browse/SLES-2961
Overview
SNS→SQS→Lambda trace propagation breaks when the
_datadogcontext attribute reaches SQS as a Binary message attribute (e.g. via SNS raw message delivery). The consumer Lambda starts a new trace instead of continuing the publisher's.SqsRecord::get_carrier()only checkedstring_valueon the_datadogattribute. When the attribute was Binary-typed, that check silently failed and the code fell through to parsing the SQS body as an SNS envelope — which doesn't exist under raw delivery — so it returned an empty carrier. The SNS-native path (SnsRecord::get_carrier()) already branches on the attribute's type and base64-decodes Binary values; the SQS-native path never got the same treatment.Fix: branch on
data_typeinSqsRecord::get_carrier(), base64-decoding the Binary case before parsing the carrier JSON, matchingsns_event.rs.Testing
sqs_event_binary.jsonfixture andtest_get_carrier_binary, reproducing the bug (fails without the fix, passes with it).cargo test --lib— 145 trigger tests pass.cargo clippy --lib -- -D warnings— clean.