ThreeFire1 opened a new issue, #18721: URL: https://github.com/apache/dolphinscheduler/issues/18721
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/dolphinscheduler/issues?q=is%3Aissue) and found no similar issues. ### What happened `AbstractWorkflowStateAction.workflowFinish()` changes the shared workflow instance to a final state before the transaction commits. If the workflow update succeeds but deleting the serial command throws, the transaction rolls back. The database still has `RUNNING_EXECUTION`, but the in-memory instance is already `SUCCESS`. When the Master retries the finish event, the final-state action skips it, leaving the workflow stuck and blocking the next serial instance. I reproduced this in a local Master/H2 integration test. A failure injected just before transaction commit produces the same result. The method also records the completion metric and publishes the finalize event before commit. ### What you expected to happen After a rollback, the in-memory workflow should remain eligible to process the retried finish event. The shared final state, end time, completion metric, and finalize event should only be updated or emitted after a successful commit. ### How to reproduce Tested on dev commit `c70003c2aa325a143e033e6b753ac7de30ec31a9` using the existing Master integration test framework and H2: 1. Start two instances of a SERIAL_WAIT workflow. 2. Make the first call to `SerialCommandDao.deleteByWorkflowInstanceId()` throw `DataAccessResourceFailureException`. All other DAO calls use the real implementation. 3. Let the Master retry automatically, without restarting it or manually replaying the event. 4. The first workflow remains `RUNNING_EXECUTION` in the database, while its in-memory state is `SUCCESS`. The retry skips the finish event, and the second instance cannot complete. A separate test injects an exception in a transaction synchronization's `beforeCommit` callback and reproduces the same rollback problem. These tests use real H2 transactions with injected exceptions. ### Anything else #18698 discusses stale serial commands and crash/failover recovery. This reproduction does not require a Master restart: the finish event is retried, but the prematurely changed in-memory state causes it to be skipped. My proposed approach is to persist a copy of the workflow instance and apply the in-memory changes and completion actions after the transaction commits. I would also cover duplicate finish calls and transaction callback failures, including when the method joins an outer `REQUIRED` transaction. I'd like to submit a PR with regression tests for the `SUCCESS`, `FAILURE`, `STOP`, and `PAUSE` finish paths. ### Version dev ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
