Monitor telemetry exporter: no way to report exception from consumer span.

[vputsenko]

Due to 21ee8ad#diff-91578a36a9cd93bc063569087dd9e7421dd054203bbf445a117c780ad4192e4aR438 all exception reported from consumer span will be ignored.

In this commit you accept exceptions either from remote span or internal span. However consider scenario:

1. Kafka message arrives
2. you extract context from headers -> context with no recording span is created. Span's isRemote property is true;
3. you call startActiveSpan to create span for message handling using extracted context and kind = SpanKind.Consumer.
4. newly created span is no longer "remote" because it is child of remote span - so exceptions are ignored.

Yes, we can set kind to SpanKind.Internal, but it breaks visual span representation in UI and semantics overall...

Note, that in this context we have enough information to report "resolved" exception.

[JacksonWeber]

@vputsenko I believe based on the scenario you mentioned above, in point 4 you say the "newly created span is no longer "remote" because it is a child of a remote span". The logic from line 438 here specifies that if the parent of the span is remote, that the exception will be created, regardless of if the span the exception is recorded on is INTERNAL. Please let me know if that logic covers your case as expected. Thanks!

[vputsenko]

@JacksonWeber in this code parentSpanContext is not a context of parent span of current span, it is just simply context of current span (look here )

Note that in Open Telemetry setting span to context creates new context and current context just used as parent of newly context (look here https://github.com/open-telemetry/opentelemetry-js-api/blob/main/src/trace/context-utils.ts#L51 ) . So in my scenario remote span stays in parent context of current context (which has newly created span as active), but your code checks current span's context.

BTW, may be i really miss something. here is pseudo code i use

1. const remoteCtx = propagation.extract(ROOT_CONTEXT, message.headers, headersAccessor);
2. tracer.startActiveSpan(topic, spanOptions, remoteCtx , (newSpan) => { newSpan.recordException(new Error('Ooops'); } )

So at step #2 context of "newSpan" is no longer remote. however remoteCtx has really remote span set as active.

In another words you can create remote context using propagation.extract but you cannot use assign it to span, you can create span with this context as parent. On server side such spans are usually Server or Consumer.

You don't catch this in your tests because you create spans using constructor, not by OpenTelemetry API. Look here https://opentelemetry.io/docs/specs/otel/trace/api/#span-creation
"There MUST NOT be any API for creating a Span other than with a Tracer."

So this test is incorrect because using OTel APi you never create remote spans to use for scope of some job.