What are error variables?

[falko]

The error events page talks about "error variables" but does not explain what that is: https://github.com/camunda/camunda-docs/blob/25854219f2b2384a73088eb8db162311432110e2/versioned_docs/version-8.5/components/modeler/bpmn/error-events/error-events.md?plain=1#L82

I assume it means the variables that can be passed to a ThrowError RPC message when failing a job in a client: https://docs.camunda.io/docs/apis-tools/zeebe-api/gateway-service/#throwerror-rpc

Or is there a way to send data with an Error Throw Event?

Or are there some magic variables, e.g. that the errorCode is automatically stored in a local variable of the catching Error Event?

I'm asking because, I would have needed one of the latter two options for a customer project and I vaguely remember seeing a feature request in that direction.

[falko]

@jothikiruthika FYI

[akeller]

Reached out to #ask-zeebe to triage - https://camunda.slack.com/archives/CSQ2E3BT4/p1714160024787079

[mustafadagher]

ZPA triage:

• Documentation could be improved to detail what these error variables are
• This needs further investigation whether or not this is related to an existing bug in Zeebe
• To be checked if this is related to https://github.com/camunda/zeebe/issues/11185 , https://github.com/camunda/zeebe/issues/11163, https://github.com/camunda/zeebe/issues/13940
• The question is there a way to send data with an Error Throw Event? needs to be investigated as well, it could be a missing feature
• Low likelihood, and low severity

[mustafadagher]

@falko what is the urgency on this from your side?

[falko]

@mustafadagher Either of the following feature requests would be a solution for the customer to "send data with an Error Throw Event":

• Preferred: https://github.com/camunda/zeebe/issues/13940
• Workaround: https://github.com/camunda/zeebe/issues/11459 (here we would encode data into a dynamic error/escalation code and use a catch all event to retrieve it)

There is a workaround to use a message throw event in the child process and a message boundary event on the call activity in the parent process. However, that involves an extra job worker and is much more expensive in high-performance scenarios. This workaround could be improved by sending messages directly inside the engine. But that would likely still come with correlation overhead while Errors/Escalations directly go to the parent process.

[falko]

Urgency is medium. It can be worked around by throwing more hardware at the problem, but the hardware budget for this customer is already quite high

[falko]

@jothikiruthika will investigate if a multi-instance completion condition could solve it for her customer.