Modulith Observability does not support @RabbitListener

[sfilipiak-inpost]

I tried to use RabbitMQ Externalized events for cross module communication and I noticed that produced traces differ from regular @Async @TransactionalEventListener traces i.e. RabbitMQ Externalized events don't contain modulith specific metadata.

customer::order-created receive trace should contain one more span customer: customer.

It seems to be caused by the fact that RabbitListenerAnnotationBeanPostProcessor is registering endpoints (listener methods) before they are advised by ModuleTracingBeanPostProcessor.

I tried to proxy my @RabbitListener bean but it also didn't work, because ModuleTracingBeanPostProcessor failed to correctly recognize it as a proxy and didn't advise it as well.

I am attaching sample application where issue can be reproduced.
modulith-rabbitmq-tracing.zip

P.S. I guess the same issue would occur when using @KafkaListener but I didn't test it.
P.S.2 Please also notice that currently we would be required to make such listener methods public in order to be advised. I believe it would be nice if following method from ObservedModuleType class could be modified to also support @RabbitListener, @KafkaListener and maybe other externalized event sources.

public boolean shouldBeObserved() {

	if (type.getType().isMetaAnnotatedWith(Configuration.class)) {
		return false;
	}

	return type.isController()
			|| listensToOtherModulesEvents()
			|| module.exposes(type.getType());
}

[odrotbohm]

We indeed have to make sure the Modulith observation interceptor gets added before the instance is handed off into the message listener container configuration. Otherwise, as you have correctly diagnosed, the invocation will bypass the interceptor and no module entry is recorded.

Playing with a prototypical fix I have here, we'd still end up with the module entry recorded as a nested step within the RabbitListenerEndpointContainer invocation, as that's what's invoked first and that infrastructure creates a span explicitly. I'll consult with the observability team, but right now, I don't see a good way to flip that around.

Regarding the need to make the type public: we currently don't explicitly detect message listeners as entry points, but it seems like looking for an @MessageMapping should be a reasonable way to achieve this.