It would help if triggers could propagate tracing / tellemetry context, so that workflow context would become child of the propagated context
My use case:
Currenty HTTP triggers do support reading OpenTellemetry headers and setup the propagated context as parent. This parent is then used in outbound calls thus allowing ditributed trancing.
However this is not made in a generic way - for example a Kafka trigger does not have a similar mechanism (nor publishing a message to Kafka uses the context, which is however, a separate issue). My proposal is to change the core contract for triggers (possibly emit()) so that a parent context could be propagated, as well as standarding the way triggers propagate it, with a helper for standard OpenTellemetry way, active by default. It would be useful to be able to add a generic configuration to ANY trigger that would allow to extract a perent context data - for example using a different header or based on some metadata (let’s assume we have a datat object stored in some service, eg. S3 - if the context is stoted in the object’s metadata, we shall be able to retierve it).
As a minimum reacting to OpenTelemetry propagated context as well as option of pushing current context out for protocols other than HTTP is needed.
Any resources to support this?
Are you willing to work on this?
Yes