SbloodyS commented on issue #18698: URL: https://github.com/apache/dolphinscheduler/issues/18698#issuecomment-6189530648
Based on the 3.4.3 source, this report does not yet establish a separate crash/failover bug. [Source evidence] Although persisting task failure and advancing the in-memory graph are separate operations, recovery includes event replay. `WorkflowFailoverCommandHandler` rebuilds the execution graph using existing task instances, and `TaskFailureStateAction.onStartEvent()` republishes `TaskFailedLifecycleEvent` for a task already in `FAILURE`. This re-enters the retry, failure-chain marking, and topology-transition logic. Additionally, `workflowFinish()` updates the workflow state and deletes its serial command within the same transaction. [Assessment] A `FAILURE` task within a `RUNNING_EXECUTION` workflow is insufficient evidence of a stuck workflow: the task may be awaiting retry, or other branches may still be running under the Continue failure strategy. Independent serial-command reconciliation could be a resilience improvement, but its absence alone does not demonstrate that recovery fails. To confirm the bug, please provide a minimal reproduction on 3.4.3, including the DAG, failure strategy, retry settings, serial execution mode, exact crash injection point, and Master logs covering failover and recovered execution. Timestamped database records should show that the workflow remains stuck after retries and other branches have finished, with a subsequent serial instance still blocked. The key missing evidence is where recovery stops progressing despite the failure-event replay path. -- 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]
