Hello. My team has been working with Camunda for a few years now, but recently we’ve run into an odd scenario where sometimes, Camunda process instances do not appear to flush their contents to the ACT_HI_PROCINST table. This is what we’re doing roughly:
-We first do some processing and set some results in delegateExecution variables. We then set the delegateExecution process business key to something that we can refer to later.
public void execute(final DelegateExecution delegateExecution) throws IOException {
//do some logic and set Camunda vars
delegateExecution.setProcessBusinessKey(businessKey);
}
-Then, later on, we resume this process when a user takes action, like so:
The problem is, sometimes (but not always) for unknown reasons, our users are getting the following error message, which prevents them from going forward with the transaction:
“Cannot correlate message ‘resume_message’: No process definition or execution matches the parameters.”
When we go into the ACT_HI_PROCINST table to check on this, we find that there is no rows that match the businessKey. In other words, it appears as if the business key, or maybe the process instance in general, was never written to the DB. Has anyone experienced something like this before? It has left our team somewhat bewildered as to what could be going on.
As a side note, I’ve read elsewhere that Camunda does not flush its contents to the DB until it reaches a wait state. After creation, our process goes straight to an event based gateway, which waits for the resume_message. To my understanding, this means that the data should always be flushed to the DB after our process starts. We are not seeing any errors before it reaches this wait state.
Did you set the message name to “resume_message” in your “message intermediate catch event”?
This error seems to be occurring because when the message correlation event is triggered, the instance may not be in its gateway at that time… and this may be causing the error.
My question is… were there any cases where the message was correctly correlated?
Or are there also other types of events in your gateway that could be triggering the mechanism to make the instance “move”?
Regarding the transaction points in the database, in fact camunda only saves the state when it reaches a “stopping point”, that is, where the instance is stopped waiting for something… it could be an event-based gateway, a user task, or similar things.
But you can use the Asynchronous continuation mechanism to create a new transaction point in your process… which can be Async before or after.
Below I leave the link to the official documentation on this subject, where you can see and better understand the details.
Yes, the message intermediate catch event is named resume_message. And yes, most of the time, users are able to resume the process, and do no receive the error. We do have another message intermediate catch event called “cancel_message”, which is attached to the same process. The idea is that a user can either resume a transaction, or cancel it. It would make sense to see this error if a user previously cancelled a transaction and then tried to resume it, but this is not what we are seeing in the Camunda DB tables. Instead, when a transaction is pending on a user (before any action has been taken on the transaction), the users get the aforementioned error. When we look in the Camunda ACT_HI_PROCINST table, it appears as if Camunda never wrote the process instance to the DB. This suggests that the process may never be getting to a “wait state”.
Nothing is marked as async in our flow. Before the wait state, there is only one service task, and after the wait state there is also one service task, so I don’t believe we need async processing. I’ll attach a picture of what our flow looks like for reference.
Later on, the user provides the business key of the transaction they want to process (and whether they want to resume or cancel the transaction). In the code, this is accomplished by doing this:
By that point, the users sometimes get the error, and they are unable to take action on the transaction, because the process instance does not appear to exist in Camunda.
