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) > > > > > > >