Explicit trace ID propagation for SFN w/o Hashing#537
Conversation
Add route tags
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| @@ -415,7 +452,9 @@ def is_legacy_lambda_step_function(event): | |||
| return False | |||
|
|
|||
| event = event.get("Payload") | |||
There was a problem hiding this comment.
🟠 Code Quality Violation
variable name is the same as a function parameter (...read more)
A function parameter should only be read and not be modified. If your intent is to modify the value of the parameter, return the value in the function and handle the new value in the caller of the function.
|
|
||
| # todo: testme | ||
| # e.g. arn:aws:states:us-east-1:123456789012:stateMachine:stateMachineName | ||
| if source.event_type == EventTypes.STEPFUNCTIONS: |
There was a problem hiding this comment.
This will parse the ARN so we we get trigger tags like this
| return "" | ||
|
|
||
|
|
||
| def _generate_sfn_parent_id(context: dict) -> int: |
There was a problem hiding this comment.
Created these helpers to pull hashing and hex related details out of extract_context_from_step_functions as it was getting pretty verbose
datadog_lambda/tracing.py
Outdated
| meta = {} | ||
| dd_data = event.get("_datadog") | ||
|
|
||
| if dd_data and dd_data.get("serverless-version") == "v2": |
There was a problem hiding this comment.
What is the difference between v1 and v2? Should we start from version v2 or v1?
There was a problem hiding this comment.
There's no v1, I think we can start from v1 instead if we want
I think @kimi-p suggested v2, maybe because the "legacy" context is implied to be v1
There was a problem hiding this comment.
In my opinion, "V2" may be somewhat confusing to customers because there is no explicit reference to "V1" at all.
kimi-p
left a comment
kimi-p
left a comment
There was a problem hiding this comment.
One question regarding the legacy lambda check that I think we need to update, otherwise LGTM! Thank you!
Co-authored-by: kimi <47579703+kimi-p@users.noreply.github.com>
kimi-p
left a comment
kimi-p
left a comment
There was a problem hiding this comment.
@joeyzhao2018 Could you take a look to confirm that we are using the right extraction pattern in this PR?
6 participants
What does this PR do?
Forked off of #526, this PR will use context objects to generate traceIDs rather than generating them form hashes
Add logic to extract trace context from
_datadogfor Step Functions cases where...x-datadog-trace-idbut we need to compute thex-datadog-parent-idusing parent SFN context objectx-datadog-trace-idandx-datadog-parent-idfromRootExecutionIdand the parent SFN context object_datadogand we instead figure out context from the Execution and State infoAlso fixed the trigger tags parsing for our use case!
Motivation
Testing Guidelines
Additional Notes
Types of Changes
Check all that apply