Move active_job out of messaging domain

[thompson-tomo]

Currently the active_job instrumentation is using the messaging domain however the functionality of active_job doesn't fit that of a messaging system. For instance I in the past attempted to have signalr, mqtt Brooker & nats defined but was told they are not messaging systems.

As such on further looking at it, the purpose of active job is a task/Workflow framework for which we have no conventions. I attempted to define on but did not progress due to lacking of a sig.

As such I would propose the following changes to this instrumentation which is in alignment with #2361

old attribute	new attribute	comments
code.namespace	rails.active_job.task.name	sourced from job.class.name
messaging.system	rails.component.name	'active_job'
messaging.destination	rails.active_job.queue.name	sourced from job.queue_name
messaging.message.id	rails.active_job.job.id	sourced from job.job_id
messaging.active_job.adapter.name	rails.active_job.adapter.name	sourced from job.class.queue_adapter_name
messaging.active_job.message.provider_job_id	rails.active_job.job.external_id	sourced from job.provider_job_id
messaging.active_job.message.priority	rails.active_job.job.priority	sourced from job.priority

The span kinds should be also switched to internal or maybe client?

[arielvalentin]

What's the advantage of using custom semantics over messaging semantics?

[thompson-tomo]

So the biggest thing is it would enable us to stabilise the definition as the ruby sig can own the conventions and then release a v1 gem.

Anyway semconv no longer puts vendor specific under the domain ie messaging but vendor is the domain.

Using messaging conventions doesn't actually bring any benefit given the existing semconv attributes we do use, we are overloading their meaning and in the process losing clarity. For instance looking at messaging.message.id it is not clear that message is in fact a job.

[arielvalentin]

So the biggest thing is it would enable us to stabilise the definition as the ruby sig can own the conventions and then release a v1 gem.

Anyway semconv no longer puts vendor specific under the domain ie messaging but vendor is the domain.

This part is indeed something we must fix.

Using messaging conventions doesn't actually bring any benefit given the existing semconv attributes we do use, we are overloading their meaning and in the process losing clarity. For instance looking at messaging.message.id it is not clear that message is in fact a job.

I chose to use messaging semantics because ActiveJob is a point-to-point queuing architecture,
I.e. a single message is executed by a single consumer. If some of the attributes I chose conflict with the semantics, then I agree that we should probably change that to something more suitable.

I don't think that continuations changes that. The model there to me seems like a multi stage point-to-point producer-consumer model; but maybe I'm being naive.

🤷🏻‍♂️I guess I don't see what the problem is but agree we should do whatever benefits our end users.

[arielvalentin]

Follow up question to this. In the description you received feedback from someone? that those were not messaging systems and therefore not appropriate to use for messaging semantics.

Is there some assertion that messaging systems have inherent properties like they must implement a topic-subscriber model?

Is there some assertion where they think low level client libraries tied to a specific implementation like AMQP or Kafka are the only valid protocols when describing messaging producers and consumers?

[thompson-tomo]

I chose to use messaging semantics because ActiveJob is a point-to-point queuing architecture,
I.e. a single message is executed by a single consumer.

That sounds more like a task/Workflow to me akin to the cicd or even faas domain.

I don't think that continuations changes that. The model there to me seems like a multi stage point-to-point producer-consumer model; but maybe I'm being naive.

That even more sounds like the cicd/faas domain.

In the description you received feedback from someone? that those were not messaging systems and therefore not appropriate to use for messaging semantics.

Yes I raised pr's to get the 3 messaging systems mentioned added but they were rejected due to them not being a messaging system. I tried to find out what the requirements are but that went no where. The only test I know that is done is google "is xyz a messaging system" but there is others as signalr passes that test.

Let's flip it, what in the messaging domain do we actually use? All I can see is destination & message with the later not really fitting https://opentelemetry.io/docs/specs/semconv/messaging/messaging-spans/#message as we are setting it to the job id.

In continuations won't the job id be the same for each continuation hence it doesn't define the id of the message envelope?