[Discussion] Message Start Event element and messageNameUuid generation

[johnBgood]

Describe the Bug

[Not a bug per se, more of a discussion]

Even after changing the Connector's Kafka topic and its BPMN's process ID, both old and new process definitions are instantiated after producing a message to the new topic.

See this initial ticket, and especially this comment.

Steps to Reproduce

1. Create a new BPMN file in Desktop Modeler with a Kafka Start Message Event Connector with topic S
2. Deploy the process (let's call it process A)
3. Edit the new BPMN by changing the process ID and by changing the topic to T
4. Deploy the process (process B). There should now be two separate process definitions (A and B) visible in Operate.
5. Produce a Kafka message on topic T
6. A new instance for both A and B is created
7. Produce a message on topic S
8. A new instance for both A and B is created

This is due to this property that is generated only once for a connector (changing any property won't lead to a new uuid).

Expected Behavior

1 instance should be created for A, and 1 other instance should be created for B.

Not sure if there's a good solution, or even if we want to change this behavior. Curious to get your thoughts :)

[barmac]

Hi, Thanks for creating an issue. I'd suggest to focus on the general element templates topic as a Kafka connector is just a specific implementation. From the core modeling perspective, we don't control how an engine reacts to the deployment.

Right now, if the generatedValue property is used, the initial value is generated when the template is applied to the element. Changes to other elements do not trigger regeneration as they are outside of the element.

Can you please expand on what the problem you see? Is this related to how templates work, or is it rather an issue with the deployment?

[johnBgood]

Changes to other elements do not trigger regeneration as they are outside of the element.

I think this should be true, except for the ProcessId. As a user, changing this ID means it's now a different process but I might be wrong.

This is what happened to a customer who had the same message subscription for both the initial Process and the "new" Process (after changing the ID). Does that make sense to you? I might have wrong expectations as well :D

[nikku]

As a user, changing this ID means it's now a different process but I might be wrong.

Changing the process ID is very dangerous, and doing it in production can have the exact consequences you describe: The new version is not being picked up as "the same thing" anymore, and hence across engine, connectors, ... many bad things happen.

I'd rather (if you ask me) handle this via a "do you really want to change the process ID, this may have unintended consequences" hint.

[nikku]

Us accounting for this looks like heavily investing to mitigate an edge case, at the wrong time.

[johnBgood]

That makes sense to me as well, I'll keep that in mind and I'll remember it as a bad practice then.

Thank you both, I guess we can close this issue :)