What is difference setting message correlation inside/outside a delegate

What is difference setting message correlation inside/outside a delegate?

I have a process like this,

Test 1
When I set message correlation from outside of the process like this, the message boundary event gets triggered, and the workflow exits gracefully with “say Hello”.
I correlate the message in a Spring controller

@PostMapping("/foo")
public ResponseEntity<?> foo(FooRequest request) {
    ...
    runtimeService.createMessageCorrelation(Constant.MESSAGE_FOO)
                .processInstanceBusinessKey(request.getBusinessKey())
                .correlate();
    ...
}

Test 2
BUT, if I put the correlation logic in a Listener or Delegate, it failed. Here, I put the same code/logic in a Listener, which is set as a Start Listener in step-1. From the log, I did see the Step-2 is invoked. But it then got invoked again and failed with a different executionId.
The error message is like this,

"Execution with id '2731f374-85ae-11ea-b35d-92883b51563c' does not have a subscription to a message event with name 'msgFoo': eventSubscriptions is empty",

Here is my question, with the same setting of message correlation, test-1 was successful. but test-2 failed. and why the listener which sets the message correlation got invoked multiple times in test-2? I’ve verified, the failed execution belongs to the same process instance.

So this is because the BPMN standard requires that a message event cannot be triggered from within the same scope.
So this means that a process cannot sent a message to itself. Instead you should either look into using conditional events which are much easier to trigger from within the same scope.

Thank you, Niall. “process cannot sent a message to itself”. Yes, this is why. Kept thinking the boundary event could capture message within the scope. Thank you for clarify.

But, why I am seeing the event handling branch was triggered? Actually the first trigger was the right one, but then followed by another failed trigger which should not happen

Used Signal event perfectly resolved this issue. thanks!