'Cannot correlate message' after deploying and deleting another version of the process

I modeled a process with a start message named ‘StartProcess’.
An instance of that process version 1 could perfectly be created with a REST POST /message.

We deployed version 2 of that process that renamed the start message to ‘NewDocument’. After deleting version 2, version 1 is activated again but ‘StartProcess’ could not be correlated.

This is reproducable.

Hi Hubel,

what do you mean by “After deleting version 2”? Are you deleting the process instance or process definition? If you’re using REST API which specific call are you making?

Could you check if after “deleting version 2” you still have process version 1 deployed?

When the message ‘StartProcess’ can not be correlated, what response do you get? Could you also check logs if there is some exception regarding message correlation there?

Svetlana

I believe this is the same issue as this but with messages instead of timers: https://app.camunda.com/jira/browse/CAM-5379. Haven’t verified this, though.

Hi, Thorben,
I’m not sure. I played with it a little yesterday, I modified one test that we have for message correlation and it worked fine for me. Here is what I tested:

deployment(Bpmn.createExecutableProcess("process")
    .startEvent()
      .message("a")
    .userTask()
    .endEvent()
    .done());
final String deploymentId = deployment(
  Bpmn.createExecutableProcess("process")
    .startEvent()
      .message("b")
    .userTask()
    .endEvent()
    .done());

ProcessDefinition firstProcessDefinition = repositoryService.createProcessDefinitionQuery().processDefinitionVersion(1).singleResult();
ProcessDefinition secondProcessDefinition = repositoryService.createProcessDefinitionQuery().processDefinitionVersion(2).singleResult();

runtimeService.createMessageCorrelation("a")
  .processDefinitionId(firstProcessDefinition.getId())
  .processInstanceBusinessKey("first")
  .correlateStartMessage();

runtimeService.createMessageCorrelation("b")
  .processDefinitionId(secondProcessDefinition.getId())
  .processInstanceBusinessKey("second")
  .correlateStartMessage();

assertEquals(1, runtimeService.createProcessInstanceQuery()
    .processInstanceBusinessKey("first").processDefinitionId(firstProcessDefinition.getId()).count());
assertEquals(1, runtimeService.createProcessInstanceQuery()
    .processInstanceBusinessKey("second").processDefinitionId(secondProcessDefinition.getId()).count());

runtimeService.deleteProcessInstance(runtimeService.createProcessInstanceQuery()
  .processInstanceBusinessKey("second").list().get(0).getId(), "test");

repositoryService.deleteDeployment(deploymentId);

runtimeService.createMessageCorrelation("a")
  .processDefinitionId(firstProcessDefinition.getId())
  .processInstanceBusinessKey("first")
  .correlateStartMessage();

assertEquals(2, runtimeService.createProcessInstanceQuery()
  .processInstanceBusinessKey("first").processDefinitionId(firstProcessDefinition.getId()).count());

Hubel, could you check if it’s the same scenario as you’re testing?

Thanks for checking @sdorokhova. @Hubel, engine version could also be of interest.

I use the Cockpit to delete the deployment with the ‘cascade’ option set and don’t know which REST command this corresponds to.
I just checked that even if I do not rename the start message the exception occurs after deleting the latest deployment.
Exact error message from POST /message:

{
	"type": "RestException",
	"message": "org.camunda.bpm.engine.MismatchingMessageCorrelationException: Cannot correlate message 'startProcess': No process definition or execution matches the parameters"
}

Engine version is 7.6.

Thank you for your effort to retrace this issue.
As far as we could assess the underlying call sequence, what we did regarding the correlation is the same as in your example, Svetlana. Maybe it comes down to the way I deleted the deployment.

Hi Hubel,
I digged a little bit more into the problem and finally created a bug issue: https://app.camunda.com/jira/browse/CAM-7838
@thorben was right, this is similar behaviour to timer start events. When second version of process is deployed, the subscription to messages of 1st version is being canceled (documented here https://docs.camunda.org/manual/7.6/reference/bpmn20/events/message-events/#message-start-event). But if the second version of process is undeployed, message subscription must be created again.

My test was working, because I was providing processDefinitionId, when correlating a message. In this case it is working. Please consider this as a workaround for your problem, unless the bug is fixed.

Thank you for reporting the issue!

All the best,
Svetlana

2 Likes