That is fine. I am a bit overloaded right now with the reusable engine and trying to remove the assembly stuff from jbpm. Mind to write the proposal ? I think more or less everything is set
El lun, 6 may 2024 a las 15:00, Francisco Javier Tirado Sarti (<[email protected]>) escribió: > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
