About 4. Ideally, when aborted on error (or bad_creation), we should set the error code to something different than 201 (which is returned now if one ActionNode abort the process). I would that should depend on the type of error, but typically will be either 400 (wrong params) or 500 (some sync external call failed)
On Mon, May 6, 2024 at 12:42 PM Enrique Gonzalez Martinez < [email protected]> wrote: > Hi Francisco, > I would say to set a general policy for every process and we could > fine tune the behaviour with the metadata. I would say that trying to > set the policy in the metadata as a primary use case could be too > verbose for the end user. > Regarding the state, I would say reusing the current state would be > more than enough. In the end if this happens it would remove the > process from the process instance table and just send the data index > /data audit for knowing something happened. > The other aspect I can see with this is subprocess as they might need > to have some sort guard to avoid being aborted, otherwise it would > cause problems (stale the parent process). In order to make this work > we need to set certain constraints. > > 1. being able to set a policy for process (we should be able to set > the policy for process / subprocess). The impact for aborting > subprocesses is too high. > 2. We need to think about what to do with data audit / data index. > 3. setting the state as abort should be more than enough to get rid of > the info in storage. but I am open to discuss a new state as > BAD_CREATION os something that represents a top level instance not > being able to create. > 4. what to do with the rest endpoint http code. > > Cheers :) > > El lun, 6 may 2024 a las 11:13, Francisco Javier Tirado Sarti > (<[email protected]>) escribió: > > > > I agree, but more than avoiding process instance creation (because the > user > > would certainly want to see that there was a failed execution because of > > wrong input parameters in the management console) I would say that when > > setError (the line you linked) is invoked over the process instance, > > depending on metadata, we abort it or we keep it alive (as we are doing > > now). If we do so, this leads to a further question ;), we set the final > > state abort (as it was manually aborted) or we create another process > > instance state (error_aborted)? > > > > On Mon, May 6, 2024 at 11:04 AM Enrique Gonzalez Martinez < > > [email protected]> wrote: > > > > > Hi Francisco, > > > > > > I can see the problem. This is not about reacting to an error, this is > > > regarding how we create process instances. In v7 we did not have this > > > problem because we only did have two different things to avoid this: > > > 1. one single point to create and start a process > > > 2. transactions that fail if something wrong happend during the first > > > process instance transaction execution. > > > > > > This was causing when the system not having to deal with processes not > > > properly created as the creation of the process was tied to the > > > execution of the first transaction making not possible to have a > > > process instance not workable (at least for the first transaction) > > > > > > Now this is not the case. You create the process instance > > > independently from the start event of the process instance causing > > > this sort of problem. As I did mention before Error means still alive > > > but some sort of required human intervention. So I am not really keen > > > to revisit this. > > > As I did say in my previous email I am open to discuss certain aspects: > > > > > > * I am open to discuss re triggering mechanisms. > > > * I am also open to discuss certain abortion policies if certain > > > criterias are met. > > > > > > As you mentioned > > > "Another possible solution, rather than a timeout, is to allow > > > automatic abortion of a workflow which suffers an error." > > > > > > which fits exactly my second bullet and I am pretty open to go back to > > > certain v7 behaviour related to how the system works when you create > > > the process. > > > > > > The idea IMO would go around this call > > > > > > > https://github.com/apache/incubator-kie-kogito-runtimes/blob/fed1bd142a466d6be4e75e3972729278f65cabcc/jbpm/jbpm-flow/src/main/java/org/jbpm/workflow/instance/impl/NodeInstanceImpl.java#L261 > > > and hot to implement those policies to avoid process instance creation > > > if it fails in new process. > > > > > > El lun, 6 may 2024 a las 10:39, Francisco Javier Tirado Sarti > > > (<[email protected]>) escribió: > > > > > > > > The reason I opened this thread is because there are some concerns > from > > > > user stale processes in error. Let me quote one of them > > > > "I can see the system being flooded with those instances in case of > wrong > > > > params or an system which is down that fails the flwo" > > > > Therefore, the use case certainly exists and we need to cope with it > > > > somehow. > > > > Another possible solution, rather than a timeout, is to allow > automatic > > > > abortion of a workflow which suffers an error. That makes sense for > > > > workflows which are unlikely to be retriggered. Maybe we can add > process > > > > metadata to indicate a process should be aborted when an error > occurs. > > > > > > > > On Fri, May 3, 2024 at 10:01 PM Enrique Gonzalez Martinez < > > > > [email protected]> wrote: > > > > > > > > > To be honest error state in a process is a bit strange. Anyway at > this > > > > > point it means that the process is active and stale for some > reason. > > > > > > > > > > Recovery should be something that historically needs to have some > human > > > > > intervention so i dont see why would you try to clean up anything > in > > > the > > > > > system. The instance is alive but staled. Aborting a process > should be > > > done > > > > > manually. We cannot make a decision on behalf of the user. > > > > > > > > > > I am open to discuss re triggering mechanism but not for aborting > > > process > > > > > instance automatically. It does not cover a real use scenario. > > > > > I am also open to discuss certain abort policies if certain > criterias > > > are > > > > > met. > > > > > > > > > > -1 to the proposal. > > > > > > > > > > > > > > > El vie, 3 may 2024, 13:11, Francisco Javier Tirado Sarti < > > > > > [email protected]> escribió: > > > > > > > > > > > Hi all, > > > > > > According to my interpretation of the engine code [1], all > > > unexpected and > > > > > > unhandled errors during node execution are currently intercepted > and > > > the > > > > > > process state is set to Error, but the process instance remains > > > active to > > > > > > allow users to update the model and retrigger process instance > > > execution. > > > > > > Although a clever approach to allow recovery of processes that > uses > > > do > > > > > not > > > > > > want to execute again from start (they might have failed because > > > there > > > > > was > > > > > > a typo in a human task), this potentially creates a large number > of > > > idle > > > > > > process instances that are not going to be deleted from memory/db > > > > > > (depending if persistence is configured or not, in production it > > > will be) > > > > > > unless the users manually abort them. If the user does not > monitor > > > them, > > > > > > this policy might jeopardize the performance of the whole > > > application. > > > > > > I would like to explore the possibility of setting a timeout for > > > process > > > > > > instances on error (that will be of course configurable). If the > > > process > > > > > > instance has not been acted upon for a reasonable amount of > time, it > > > will > > > > > > be automatically aborted. > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/jbpm/jbpm-flow/src/main/java/org/jbpm/workflow/instance/impl/NodeInstanceImpl.java#L247-L251 > > > > > > > > > > > > > > > > > > > > > > > -- > > > Saludos, Enrique González Martínez :) > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
