+1, I think that adding the field in data-index graphql schema will be the easiest
On Fri, 28 Mar 2025 at 12:43, Francisco Javier Tirado Sarti <ftira...@redhat.com.invalid> wrote: > 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 > > > > > > > > > > > > > >
