fix: register lambda span

[xuan-cao-swi]

Description

The aws lambda span was not registered with context after start_span, which cause current_span can't detect it. User couldn't append attributes outside call_wrapped span. This PR attach the span to current context and detach it before finish.

[kaylareopelle]

Why did you decide to make this an instance variable?

[xuan-cao-swi]

In case the process fail, on the ensure part, OpenTelemetry::Context.detach(@trace_token) if @trace_token won't throw error (e.g. undefined local variable or method 'trace_token' for ...)

[kaylareopelle]

Got it! I understand wanting to prevent undefined errors, and I think we can achieve that with a local variable.

One option could be to update the existing guard clause to use if defined?(trace_token).

Another option could be to add a line to define trace_token earlier on in the method, like we do for span_kind, and then use if trace_token in the guard clause:

def method
  trace_token = nil
  # ... 
ensure
  OpenTelemetry::Context.detach(trace_token) if trace_token
end

Would one of these options work for you?

[xuan-cao-swi]

Yes, I will take the local variable, thanks!

[kaylareopelle]

Thank you!

[cheempz]

@xuan-cao-swi I'm curious whether you tried using tracer.in_span instead of tracer.start_span and having to explicitly manage the context.

Since you're already using OpenTelemetry::Context.with_current(parent_context) in line 43 above to propagate any incoming context into the current one, in_span should be able to continue that and as a benefit record exception too. Some examples in exising "server" or "consumer" instrumentation that deal with the same concern of propagating incoming context from external process, setting it into current process's context, and starting a span.

[xuan-cao-swi]

Thanks, I agree in_span is a better choice for this instrumentation. Updated!