Let’s say that I create an instance of my flow.
Then, because of the technical way I receive events, I receive first the message for Task 2 before the message for Task 1. My experience with Zeebe is that both messages will be accepted but the message for Task 2 is not taken into account i.e. the task 1 is considered as completed but the task 2 is only considered as activated although a valid message was received (but a bit in the past). If I resend the message for task 2 the task 2 is considered as completed.

Does this work “as designed”? Personally I find it a kind of shortcoming or maybe my basic knowledge of BPMN missed something.

This means that Message 2 is not caused by or dependent on task 1, so these are not really sequential. In this case, your model does not accurately model the domain.

You might be better off putting them as parallel and requiring both to advance.

If you want to keep them as sequential in the model (even though they are not in reality), then you can use message buffering to represent the maximum amount of time between the arrival of Message 2, and the subsequent Message 1.

If Message 2 has the TTL set to that period, the broker will buffer it until the message subscription becomes active.

Thanks a lot Josh for your answer.
From a business perspective Task 2 is well after task 1.
It is just that technically we cannot guarantee that the messages will arrive in sequence.
But indeed my mistake, I did not see the ttl parameter set as default to 5s. If I put it to a value that is big enough to ensure that I receive message for Task 1, message for task 2 is well taken into account and the flow is complete as expected. It is just that in Operate I don’t see that I already receive a message for Task 2; but that is somewhere normal.