add support for failed handlers

[trojanc]

Hi, It seems like currently there is no way to identify if a job has failed?

• The process instance remains in the ACTIVE state
• It doesn't look like element Exception Flow is supported, which I think would have been able to solve it inside the process itself?

Or am I missing something obvious...?

[trojanc]

I'm not sure if doing this will be according to the specification, but it at least marks the process instance as failed too... Ideally it would be nice to be able to handle failed jobs within the process

Adding to https://github.com/nitram509/lib-bpmn-engine/blob/v0.3.0-rc2/pkg/bpmn_engine/tasks.go#L31-L36

else if job.JobState == Failed{
  instance.State = Failed
}

[aamirmousavi]

Hi @trojanc

Regarding your question on error handling and SAGA patterns, have you considered if BPMN Error Events (like Error Boundary Events Or Event Subprocess) could address your needs here? They are designed for catching errors and triggering compensation logic.

The Camunda docs have a good overview (the concepts are standard BPMN):
https://docs.camunda.io/docs/components/modeler/bpmn/error-events/

[trojanc]

Hi, an "Event Subproccess" handling any errors should be good enough for my current requirement (though I could not manage to create one in Comunda editor..).

I just need a way to know when job.Fail() was called. At the moment there is no way to be aware of that. Handling it within the process using a "catch-all" should do the trick... or if it was possible to know from outside of the process e.g. looking at the process instance's state would also be fine too... At the moment when job.Fail() gets called the process instance remains ACTIVE...

Or... Am I doing something wrong? Is job.Fail() not the way cause the process to reach a failed state..?

Doing compensation is not a requirement for me right now... Just a simple way to deal with a process failing

[trojanc]

After some more reading and using AI for inspiration... I realized there are two types of failures.

Technical Error, like a "code failure", "database down", etc. I think this is what job.Fail() represents.

and Business Errors which are things you want to model, like "user out of funds", or "customer record" does not exist... This will require more models to be loaded from the XML file. And maybe a function like job.ThrowError(code string, message string)

For my current use case just dealing with Technical errors should be sufficient. That brings me back to my original question in this thread. When job.Fail() is called, the process state is not set to failed. And that reason supplied to job.Fail(reason) does not surface anywhere... having that available should allow some basic ways to gracefully deal with a process failing....

[trojanc]

This is still a work in progress... But I've implemented "Technical Errors" which is propagated all the way up to the engine and "Business Errors" which can be handled by "Error Boundary Error" or "Event Sub Proccess" in the process.

I'm still writing tests and cleaning it up, but so far it seems to be working...

#273