Redriven Step Functions Trace Merging#598
Conversation
| expect(traceContext).not.toBeNull(); | ||
|
|
||
| expect(traceContext?.toTraceId()).toBe("1139193989631387307"); | ||
| expect(traceContext?.toSpanId()).toBe("3615526381891637131"); |
There was a problem hiding this comment.
Could you link the PR line in the reducer that matches this test?
Also, is the plan to match traceID only but not spanID?
There was a problem hiding this comment.
Here's the matching line from logs-backend
Yes the lambda span should be in the same trace but we want the spanID to be different from the original when redrive count was 0
There was a problem hiding this comment.
Can you link the test just to verify that the two matches? Thanks!
|
/merge |
Devflow running:
|
|
/merge |
Devflow running:
|
|
/merge |
Devflow running:
|
What does this PR do?
Adds support for Step Functions trace merging in Redrive cases
We previously used
hash(ExecutionId # StateName # StateEnteredTime)for spanID calculation but these values are identical across redrives for a Lambda task state. The new approach also adds aRedriveCountto the end of the hash but omits this value when it is 0 to have easy backwards compatability.Motivation
https://github.com/DataDog/logs-backend/pull/84188
Testing Guidelines
Redriven Trace with Lambda and Trace Merging

Types of Changes
Check all that apply