Camunda fails to instantiate a process when error occurs after start event

Hi all,
I’m seeing this challenge with process deployment.

If an error occurs in the first or second task after the start event, camunda fails to instantiate the process.

I get this error:

Cannot instantiate process definition 1234:1:0f004d98-12ce-11e6-ba27-3ea9974dc07e: Unable to evaluate script: ReferenceError:…

As a workaround, if I place a 0-second timer directly after the start event, camunda instantiates the process and I can then look at that instance and find the error inside the incident that appears as a result of the error. This is an improvement, since I can troubleshoot easier by looking at the incident details. Before, I had to look at the API response to find the error.

The 0-second timer workaround works. However a blank/none intermediate throwing event does not achieve the same result, nor does adding a 1-second (or even 30-second) delay as an end execution listener on the start event.

Is there a way to avoid adding this timer to every process? I’d like to avoid non-business items in the visual diagram.

@Rob1 you are seeing “rollback” occurring. read about: https://docs.camunda.org/manual/7.8/user-guide/process-engine/transactions-in-processes/

Look at the logs and you will see where the errors occurred.

You can also set “async before” or “after” on the start event which will cause errors to generate a “incident”

Your timer works because a timer is a background job that creates a new/different transactions. Read about transactions in the above link. really important you understand how they work; your life will be a lot easier.

1 Like

Thanks, async after checked on the start event resolves that issue. However, what I don’t understand is why now the token and incident labels inside cockpit appear on the start event, rather than the task directly preceding the task which contains the error. In my diagram there is the start event, task 1 and task 2, with task 2 containing the error. This is confusing as it makes me believe that I need to troubleshoot task 1, when task 2 is the area of concern.

Thanks for the reference, I’ll read about it.

Edit: After reading about transactions, I assume that the token and incident labels reside over the start event because that represents the beginning boundary of that transaction, which includes both the start event and task 1, and that due to a failure they are rolled back to the beginning of the current transaction. I’ve tested this and it appears to be true. Is this a correct assumption?

Yes that is correct.

If you look at the console logs (terminal logs) and scroll up you will see a sort of graphical print out of the steps taken in the transaction and where the error occurred. Its very good to get good at reading the errors in the console as there is valuable information in there!