I am fine changing the scheme of graphql in data index to add computed fields to avoid the user to do themselves and actually i consider that a good thing as it allow us to extend the real states of the engine without impacting their calculations
El jue., 27 mar. 2025 17:56, Francisco Javier Tirado Sarti <ftira...@redhat.com.invalid> escribió: > 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 > > > > >
