[SVLS-4647] Fix lambda authorizer trace context injection issue #453
Conversation
| injected_headers[TraceHeader.SAMPLING_PRIORITY] = str( | ||
| span_context.sampling_priority | ||
| ) | ||
| propagator.inject(span_context, injected_headers) |
There was a problem hiding this comment.
Great catch, I wonder if this methods should eventually be refactored into a tracing service and not the wrapper 😕
There was a problem hiding this comment.
the propagator.inject ends up injecting into injected_headers, correct?
There was a problem hiding this comment.
Good question!
Having the same thought, I went ahead trying to refactor it.
Then I found it's already in a helper method called _inject_authorizer_span_headers.
Then it felt that the injection is more relevant to the wrapper because the wrapper now has the inferred_span or span data and it also should be responsible for the final response data. And then at this point, the injection became more like prepare_response and the only tracer related part is already encapsulated by the propagator.inject helper.
Hope this makes sense.
What does this PR do?
There's a regression introduced about authorizer span due to the hardcoded headers values broken by the changes happened in ddtrace.
Specifically, the value of trace id has been directly fetched from the span_context like this
injected_headers[TraceHeader.TRACE_ID] = str(span_context.trace_id)and thatspan_context.trace_idis now changed into a big int and causing problem when the downstream main lambda tries to extract itThe fix is to use the official propagtor from ddtrace to inject the context.
Testing Guidelines
Updated the unittest to use the
propagatortoo in order to future proof such kind of issue introduced by dependency updates.Tested in a real lambda case and see it back to normal like this:
Types of Changes
Check all that apply