difference in context propagation for 'process' and 'receive' spans

[mgevantmakher]

opentelemetry-java-instrumentation/instrumentation/jms-1.1/javaagent/src/main/java/io/opentelemetry/javaagent/instrumentation/jms/JmsSingletons.java

Line 51 in 62cc2a7

.newInstrumenter(SpanKindExtractor.alwaysConsumer());

Hello I noticed by testing JMS auto instrumentation api a difference in context propagation for 'receive' [buildConsumerInstrumenter] vs 'process' [buildListenerInstrumenter] . I'm not sure if it is intentional or not but it affects ability to display relationship between 'publish' span and 'receive' span.
Please provide guidance if this a part of 'semantic convention' or a bug.

[dpauls]

The comment above the code suggests this is intentional:
// MessageConsumer does not do context propagation

However, it isn't clear why this decision was made. It is counterintuitive that a JMS MessageConsumer would not follow the Messaging Semantic Conventions for a consumer.

[trask]

hi @mgevantmakher, @dpauls!

it's not completely clear what should be done in the receive case.

receive spans don't typically have a way to automatically track the downstream work done with the message (which differentiates them from process spans).

also often receive is called inside of another span, in which case you may or may not want to inherit that span as the parent

it does seem like we should at least add a link to the receive span, to link it to the producer somehow.

also I expect the spec to become clearer on how we should be modeling this in the near future as the messaging working group makes progress: open-telemetry/oteps#173