Yes, another option is to not add the state to Runtimes but add the state to Data index graphql possible value for process instance.state <https://github.com/apache/incubator-kie-kogito-apps/blob/main/data-index/data-index-graphql/src/main/resources/basic.schema.graphqls#L113-L120> (or maybe is better a new field) and determine if the workflow is "running" or "waiting" through the actual node event (so the user does not have to inspect the list of node instances, which is the "workaroung" I proposed when asked ), wdyt, additional value for state or new field with more details for active state?
PS: I should have opened this as "DISCUSSION", my bad ;) On Thu, Mar 27, 2025 at 4:44 PM Enrique Gonzalez Martinez < egonza...@apache.org> wrote: > Hi Francisco, > > To be honest I think this is not a bad idea but I would leave the > states aside and focus on the data events stuff. > * You can always compute if a process is in waiting state because > there are nodes with an enter date but not exit date in that regard. > * Another way to compute the waiting state is to see if the entry is > not COMPLETED or ABORTED. > > What I mean is that if ACTIVE and WAITING are synonyms there is no > point to add a state but just to produce virtual engine events like we > do with the SLA process instance state event to mark the batch. > If you want to mark somehow the end or start of the transaction like > we do with the SLA it is fine by me you just need to produce those > during operations over the process state but you won't be able to tell > when a process is RUNNING (so to speak) because of the problems > derived of how we manage events. > > > Cheers :) > > > El jue, 27 mar 2025 a las 14:45, Francisco Javier Tirado Sarti > (<ftira...@redhat.com.invalid>) escribió: > > > > I forgot to add the word "potentially" for data index users. > > Right now, since events that are consumed by data index are only sent > when > > the workflow returns control to the caller (and it return control when is > > waiting for something to happen) ACTIVE is equivalent to WAITING, > > However, if we decided, in future, to increase the number of events to > > improve data index feedback (for example, by publishing an event when the > > workflow starts execution) that distinction will start making sense. > > > > On Thu, Mar 27, 2025 at 2:38 PM Francisco Javier Tirado Sarti < > > ftira...@redhat.com> wrote: > > > > > I have opened > https://github.com/apache/incubator-kie-issues/issues/1892 > > > describing the issue. Let me elaborate here a bit more, currently we > have > > > following possible workflow states > > > < > https://github.com/apache/incubator-kie-kogito-runtimes/blob/main/api/kogito-api/src/main/java/org/kie/kogito/internal/process/runtime/KogitoProcessInstance.java#L29-L34 > > > > > > > > > > > int STATE_PENDING = 0; > > > > > > int STATE_ACTIVE = 1; > > > > > > int STATE_COMPLETED = 2; > > > > > > int STATE_ABORTED = 3; > > > > > > int STATE_SUSPENDED = 4; > > > > > > int STATE_ERROR = 5; > > > > > > > > > The idea is to add an additional one, STATE_WAITING, that will be set > when > > > the workflow > > > > > > return control to the caller (BoundaryEvent nodes mainly) > > > > > > This will allow Data Index users to know if the workflow is > active-waiting > > > or active-running. > > > > > > > > > For all other purposes, the workflow will still be active. Therefore, > > > implementation wise, everyplave in where there is state == ACTIVE, we > > > should should state=WAITING (Ill probably add an isActive() method with > > > this check) > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > >
