-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing status flaky test #3777
base: main
Are you sure you want to change the base?
Fixing status flaky test #3777
Conversation
@@ -400,8 +400,7 @@ public void testEventBasedSplit2() throws Exception { | |||
org.kie.kogito.process.ProcessInstance<EventBasedSplit2Model> instanceTimer = processDefinition.createInstance(modelTimer); | |||
instanceTimer.start(); | |||
assertThat(instanceTimer.status()).isEqualTo(org.kie.kogito.process.ProcessInstance.STATE_ACTIVE); | |||
assertThat(countDownListener.waitTillCompleted(15000)).isTrue(); | |||
assertThat(instanceYes.status()).isEqualTo(org.kie.kogito.process.ProcessInstance.STATE_COMPLETED); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a leffover, instanceYes has already being checked (btw, this probably makes the issue less frequent adding a small delay ;))
I also restored the timer to the default value (since that was not the issue)
jbpm/jbpm-flow/src/main/java/org/kie/kogito/process/impl/AbstractProcessInstance.java
Outdated
Show resolved
Hide resolved
4177278
to
f2390de
Compare
There is a chance that status is invoked over a process instance that has been finished, but the container kogito process instance does not know yet, even if processcompleted listener has been executed (and thats the issue) Although this can be fixed by altering the order in which the different listener are invoked (which might probably have other undesired effect), I do not see a reason why status should not be read from underlying process instance, if present. Probably processInstance field should be embedded into an atomic reference, but volatile might have the same effect with few code changes.
f2390de
to
dfd99df
Compare
PR job Reproducerbuild-chain build full_downstream -f 'https://raw.githubusercontent.com/${AUTHOR:apache}/incubator-kie-kogito-pipelines/${BRANCH:main}/.ci/buildchain-config-pr-cdb.yaml' -o 'bc' -p apache/incubator-kie-kogito-runtimes -u #3777 --skipParallelCheckout NOTE: To install the build-chain tool, please refer to https://github.com/kiegroup/github-action-build-chain#local-execution Please look here: https://ci-builds.apache.org/job/KIE/job/kogito/job/main/job/pullrequest_jobs/job/kogito-runtimes-pr/job/PR-3777/3/display/redirect Test results:
Those are the test failures: org.kie.persistence.filesystem.FileSystemProcessInstancesTest.testBasicFlowExpecting value to be true but was false org.kie.persistence.filesystem.FileSystemProcessInstancesTest.testBasicFlowWithStartFromCannot invoke "org.jbpm.workflow.instance.WorkflowProcessInstance.getVariables()" because "this.processInstance" is nullorg.kie.persistence.jdbc.PostgreSqlProcessInstancesIT.testBasicFlowNo value presentorg.kie.persistence.jdbc.PostgreSqlProcessInstancesIT.testMultipleProcessesExpected size: 1 but was: 0 in: [] org.kie.persistence.jdbc.PostgreSqlProcessInstancesIT.testProcessWithDifferentVersionExpected size: 1 but was: 0 in: [] org.kie.persistence.jdbc.PostgreSqlProcessInstancesIT.testBasicTaskFlowExpecting value to be true but was false org.kie.persistence.jdbc.PostgreSqlProcessInstancesIT.testUpdateNo value presentorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testMigrateSingleProcess instance with id '93678156-9b87-4d63-9840-78bd53cf3c56' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testMigrateAllProcess instance with id '471ba762-b82c-4748-9d6c-2912f3155ace' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testBasicFlowProcess instance with id '4ae463b8-1971-4492-89e0-46a7b698cb46' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testMultipleProcessesProcess instance with id '648b8a1d-76ac-4222-a6cb-0013ca5c4436' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testProcessWithDifferentVersionProcess instance with id '0e4d0dc1-6414-4ee3-ae2d-0daa69c283f1' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testBasicTaskFlowProcess instance with id 'ca019b0b-7bb2-4dc4-b969-4ba52fc5a316' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testRemoveProcess instance with id 'a835b0c3-d594-4452-aee5-50a55738f6d0' updated or deleted by other requestorg.kie.persistence.jdbc.PostgreSqlProcessInstancesLockIT.testUpdateProcess instance with id '05beb70d-669c-4275-a42a-e928d8adf2f0' updated or deleted by other requestorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testMigrateSingleCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testMigrateAllCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testBasicFlowCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testMultipleProcessesCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testProcessWithDifferentVersionCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testRemoveCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesIT.testUpdateCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testMigrateSingleCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testMigrateAllCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testBasicFlowCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testMultipleProcessesCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testProcessWithDifferentVersionCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testRemoveCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is nullorg.kie.persistence.postgresql.PostgresqlProcessInstancesWithLockIT.testUpdateCannot invoke "org.jbpm.process.instance.ProcessInstance.configureTimers()" because "jbpmProcessInstance" is null |
Tries a first commit that read state from process insance if process instance is not null. Not working, because disconnected process instance are not null, and if set to null, it causes side effect on persistece module, Try altering the order of listeners. |
AbstracPRocessInstance.getStatus does not inmediately match WorfklowProcessIntance.getState after KogitoProcessEventListener.afterProcessCompleted is invoked (eventually they are sync). There is a chance that tests that relies on afterProcessCompleted to handle CountdownLatch receive a wrong status is they check the status just after the countdownlatch reach zero (thats why those test are flaky)