Ok, let's do that then, add a new property to the schema that provides additional information over status ACTIVE and that is calculated using the node events. Thanks for the feedback.
On Thu, Mar 27, 2025 at 7:00 PM Enrique Gonzalez Martinez < elguard...@gmail.com> wrote: > 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 > > > > > > > > >
