apache/dolphinscheduler · error · MasterTaskExecuteException

Kill SubWorkflow: ${name} failed

Error message

Kill SubWorkflow: ${name} failed

What it means

SubWorkflowControlClient.stopWorkflowInstance sends a stop (kill) request to the master host owning the sub-workflow instance; any failure of that remote call is wrapped in a MasterTaskExecuteException with this message, preserving the root cause.

Source

Thrown at dolphinscheduler-master/src/main/java/org/apache/dolphinscheduler/server/master/engine/executor/plugin/subworkflow/SubWorkflowControlClient.java:104

        } catch (Exception e) {
            throw new MasterTaskExecuteException("Pause SubWorkflow: " + subWorkflowInstance.getName() + " failed", e);
        }
    }

    public WorkflowInstanceStopResponse stopWorkflowInstance(
                                                             final WorkflowInstanceStopRequest workflowInstanceStopRequest) throws MasterTaskExecuteException {
        final Integer subWorkflowInstanceId = workflowInstanceStopRequest.getWorkflowInstanceId();
        final WorkflowInstance subWorkflowInstance = workflowInstanceDao.queryById(subWorkflowInstanceId);
        if (subWorkflowInstance.getState() != WorkflowExecutionStatus.RUNNING_EXECUTION) {
            return WorkflowInstanceStopResponse.fail("SubWorkflow instance is not running, cannot stop");
        }
        try {
            return Clients
                    .withService(IWorkflowControlClient.class)
                    .withHost(subWorkflowInstance.getHost())
                    .stopWorkflowInstance(new WorkflowInstanceStopRequest(subWorkflowInstance.getId()));
        } catch (Exception e) {
            throw new MasterTaskExecuteException("Kill SubWorkflow: " + subWorkflowInstance.getName() + " failed", e);
        }
    }
}

View on GitHub (pinned to 02eac45a1b)

Solutions

  1. Inspect the cause exception and verify the sub-workflow instance's host is reachable
  2. Check the sub workflow instance state — if already stopped, the parent retry can proceed
  3. Fix master-to-master connectivity/registry, then retry the kill operation

Example fix

// before: stale host in t_ds_workflow_instance -> update host or wait for failover
// after: correct host via failover or DB maintenance, then re-issue stop
Defensive patterns

Strategy: retry

Validate before calling

if (subWorkflowInstance.getState().isFinished()) {
    // already finished — skip remote stop
    return;
}

Try / catch

try {
    client.stopWorkflowInstance(request);
} catch (MasterTaskExecuteException e) {
    log.warn("Kill sub workflow failed, retrying", e);
    retryWithBackoff(3, () -> client.stopWorkflowInstance(request));
}

Prevention

When it happens

Trigger: Sub-workflow host master is down or unreachable, the RPC throws (instance already stopped, host mismatch after failover), or the stop request fails mid-network partition.

Common situations: Killing a parent workflow whose sub-workflow's master has crashed, stale host addresses in the workflow instance table after failover, network/firewall issues between master nodes.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors

AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06). Data as JSON: /api/errors/a26cdaef1a4f0e7e. Report an issue: GitHub.