Example for usage around ancestorElementInstanceKey in modifyProcessInstance

[gijun19]

SDK Component

This is related to Zeebe. We have an error handler process to retrying task that threw an error.

Expected Behavior

When an error is thrown, we expect that when we call modifyProcessInstance with the process instance key of the failed task, it completes successfully and the task that threw the error is retried successfully.

Current Behavior

We had a case where an task failed within a parallel gateway process instance and the modify process instance call completed successfully but we saw no task get retriggered.

We had a case in a normal step where the following error was thrown.

Expected to modify process instance but no process instance found with key '6755399460000502`

Possible Solution

Judging by how its behaving differently in certain scenarios I have to believe its due to a configuration issue? At first glance it seems like ancestorElementInstanceKey is something we need to tweak on a case by case, but I'm struggling to find docuemntation around this and what exactly an

Steps to Reproduce

1. Task errors out and output variable is passed to Error Handler process
2. Error handler task runs and calls modify process instance task

await zbc.modifyProcessInstance({
    processInstanceKey, 
    activateInstructions: [
        {
            variableInstructions: [],
            elementId,
            ancestorElementInstanceKey: '-1',
        },
    ],
});

Context (Environment)

Documentation around these parameters being passed would prove useful to developers that are trying to adopt Camunda. It would be useful to be able to process errored tasks as expected per the documentation.

[jwulf]

Thanks for using the SDK and the feedback.

Any chance of a minimal reproducer repo that I can work with that demonstrates this issue?

[jwulf]

This is the integration test for ModifyProcessInstance:

camunda-8-js-sdk/src/__tests__/zeebe/integration/Client-ModifyProcessInstance.spec.ts

Line 24 in 7a8c696

test('Modify Process Instance', (done) => {

Does that help you at all?

[gijun19]

Hi @jwulf, thanks for getting back to me. The unit test uses ancestorElementInstanceKey with a value of -1. I guess the question here would be how do we use this property field? I'm not sure how we're supposed to configure ancestorElementInstanceKey on the fly so we can properly determine the scope in which the new element instance is created. I'm assuming this property needs to be tweaked based on where the process instance lives in the process hierarchy?

Here's a scenario, what is the difference between if i do -1 vs 0 for example? Or 1 vs -1?

In regards to a small reproducable repo it's kind of difficult. We use the SDK for my company github repos and those are private and can't be shared.

[jwulf]

The ancestorElementInstanceKey is going to be either -1 or some element instance key, which will be a uid.

The grpc protocol doc comment is:

	/**
	 * the key of the ancestor scope the element instance should be created in;
	 * set to -1 to create the new element instance within an existing element
	 * instance of the flow scope
	 */

[jwulf]

Here are some examples from the Operate codebase:

https://github.com/camunda/zeebe/blob/6966042f7393c47994175d7af1b572b820d9e0cd/operate/qa/integration-tests/src/test/java/io/camunda/operate/it/ModifyProcessInstanceOperationZeebeIT.java#L211

[jwulf]

This documentation from Camunda 7 may help understand the conceptual design of the feature, because it will follow the Camunda 7 ideas in principle:

https://docs.camunda.org/manual/7.21/user-guide/process-engine/process-instance-modification/#ancestor-selection-for-instantiation

If you could give me a minimal reproducer that would help - like you create the most simple model the demonstrates the scenario, in a repo with some code that attempts to do the process modification, then we could work together on that.

[jwulf]

Hi @gijun19, how are you going with this? Did you solve this?