Running Instances after restart or shutdown

[MaheshkumarSundaram]

Hi @ralphhanna,

Persistence of the instances are handled well. There is no problem in that.

The concern is this: Suppose if the engine shutdowns due to an external problem while there are some running instances, the states will be saved. But those running instances are not running anymore after the restart (I mean they don't auto-resume from where they were left). It seems one has to manually intervene to resume them.

Could this be rectified so that the engine will auto-resume their running instances from the saved state after restart or unexpected shutdown?

Thanks!

[ralphhanna]

You are right, it would be nice to auto-resume running instances, however, there is a risk of re-executing activities that already started that may cause some harm.

The best we hope for at this stage is identify running instances and allow an admin to resume them or control what to do, this is another point of discussion and exploration.
Thanks

[MaheshkumarSundaram]

Hi @ralphhanna,

however, there is a risk of re-executing activities that already started that may cause some harm.

Won't the status field in the items array of an instance in the DB help with this?

[ralphhanna]

But not it dies before getting to DB save which happens after completing the task
I guess we can do some sort of save that the task has started
But the question still , is it safe to call the task again? This depends on the task, that is why I opted for manual intervention

[MaheshkumarSundaram]

Hi @ralphhanna,

You have a valid point.

But the question still , is it safe to call the task again? This depends on the task, that is why I opted for manual intervention

I would say this also depends on the application as a whole.
For example,

• Manual intervention would be the best case for financial applications as repeating a task would cause critical problems.
• In case of a regular workflow tracking application, auto-resume wouldn't be that much of a problem. Suppose if a workflow tracker had around 20 instances running before unexpected shutdown, having to manually restart each and every one is cumbersome in which case auto-resume would be preferred.

So why not have a global option for the user to choose this setting. Like On and Off switch.

• If the setting is off, all the instances have to be manually resumed.
• If on, all the instances would be resumed automatically from their last saved states

Does this seem reasonable? Thanks

[ralphhanna]

Or how a provide a routine to examine stalled processes and restart This can be invoked manually or part of restart

…

Sent from my iPhone On Sep 26, 2022, at 9:26 AM, Maheshkumar Sundaram ***@***.***> wrote:  Hi @ralphhanna<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fralphhanna&data=05%7C01%7C%7Cd7a4d8aeecda4e00de3808da9fc2adda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637997955741346571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=13s71mF%2B4%2FHzEfTx%2FJI9kuUhLY1NWCPkdoHg9fPdE0Y%3D&reserved=0>, You have a valid point. But the question still , is it safe to call the task again? This depends on the task, that is why I opted for manual intervention I would say this also depends on the application as a whole. For example, * Manual intervention would be the best case for financial applications as repeating a task would cause critical problems. * In case of a regular workflow tracking application, auto-resume wouldn't be that much of a problem. Suppose if a workflow tracker had around 20 instances running before unexpected shutdown, having to manually restart each and every one is cumbersome in which case auto-resume would be preferred. So why not have a global option for the user to choose this setting. Like On and Off switch. * If the setting is off, all the instances have to be manually resumed. * If on, all the instances would be resumed automatically from their last saved states Does this seem reasonable? Thanks — Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fralphhanna%2Fbpmn-server%2Fdiscussions%2F63%23discussioncomment-3734063&data=05%7C01%7C%7Cd7a4d8aeecda4e00de3808da9fc2adda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637997955741346571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y5yQ%2FIqAY2x8B8Slj9SgEJF4BFlGcMENNeOudO%2FV8zo%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAC2XVKHAZRLIPFEDRGYEVRTWAGP7FANCNFSM6AAAAAAQS4WEVE&data=05%7C01%7C%7Cd7a4d8aeecda4e00de3808da9fc2adda%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637997955741346571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jQFyBqvqPMFCKmu%2BczXWI%2FV%2BIbucUIXxZRSf07T0w2c%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[MaheshkumarSundaram]

Hi @ralphhanna,

I suppose status field in the items array of an instance in the DB could help with this.

If the status of the current last item is:

• start or running (I'm not sure what's the status when a service task or a similar task starts) - restart the last item
• wait - restart the last item
• end - start the next element in line (I presume that the status would only change to end only after the successful execution. Otherwise it should be wait or running. right!? ).

Won't this work?

Also instead of global setting; another option is to give the users ability to do selective resumes as a config for each process. Like, when modelling we could have an option in the properties-panel to select Yes/No for a process. If yes, the instances of those processes will auto-resume; if not, no.

[ralphhanna]

In Release 1.3.26, here is what I have implemented:

1. Save State after the task start and before execution, to record for status =start
2. appDelegate.startup is now fired at the application start
3. appDelegate can now detected failed tasks with status of start
4. server.engine.invoke now takes an option {recover:true} to force restart an already started task
   Here is the sample code

    /**
    * is fired on application startup
    **/
    async startUp() {
        console.log('myserver started.. checking for incomplete processes');
        var query = { "items.status": "start" };
        var list = await this.server.dataStore.findItems(query);
        if (list.length > 0) {
            this.server.logger.log("...items query returned " + list.length);
            for (var i = 0; i < list.length; i++) {
                let item = list[i];
                console.log('-->',item.processName,item.elementId,item.type,item.startedAt,item.status);
                if (item.type=='bpmn:ScriptTask' || item.type=='bpmn:ServiceTask' )
                {
                    console.log('recovering:',item.elementId);
//                    let response =await this.server.engine.invoke({"items.id":item.id}, {},null, {recover:true});
                }
            }
        }

    }

You can now customize to auto-recover any tasks that you like.