Correlation to a non-existing process is not failing

Hi,
I’m validating for my customer correlation interaction of Camunda 8. There I found something that is not according to my understand of the spec.

Maybe my understand of the spec is incorrect, therefore posting here.

Case:

zeebeClient.newPublishMessageCommand()
        .messageName("moneyReceived")
        .correlationKey(correlationMessage.correlationKey)
        .variables(Map.ofEntries(
                Map.entry("amount", (Object) 12.5),
                Map.entry("currency", "USD"),
        ))
        .send()
        .thenAccept(x -> log.info("correlation placed with zeebe cluster. MessageKey={}", x.getMessageKey()))
        .exceptionally(e -> {
            log.error("cannot correlate message. {}", e.getMessage());
            throw new RuntimeException("cannot correlate message", e);
        });

I always get a success message even as there is no process instance waiting (not even any deploy).

According to Zeebe API RPCs | Camunda 8 Docs I would have expected some error.

Is my expectation correct or incorrect?

Hi @Michael2 - messages are independent of running processes, as you can use a message start event to start a process. The messages are published to an internal queue and processed from there. Message buffering allows for this, as sometimes a message is published before a subscription is active. The message will “time out” after the TTL has expired.

You would receive an error on that gRPC endpoint if a message with the same ID already exists, or if you are trying to publish a tenant that doesn’t exist or you don’t have access to. Otherwise, the message is published to the queue/buffer to await a subscription.

Thanks @nathan.loding ,
I wasn’t aware of this specified behavior - it does make senses tho.

Then a few follow-up questions:

  • Where can our Ops team inspect the queue of published messages not yet consumed?
  • Is there a “report” of expired messages due to TTL?

My thinking is: If some process design or developer does makes a typo, we would like to see this.

Just looking at this, there is a roadmap for Camunda published for this issue.

https://roadmap.camunda.com/c/273-react-to-expired-messages-with-a-custom-exporter

Hi @Michael2 - as @cpbpm mentioned, this is on the roadmap to implement. There isn’t a great way to see the current message queue, unfortunately, but it is on our roadmap. Please upvote that particular feature on our roadmap!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.