apache/dolphinscheduler · error · ServiceException

workflow definition cannot be deleted because it has depende

Error message

workflow definition cannot be deleted because it has dependent, {dependent task message}

What it means

Thrown (with a plain message string, no Status code) when workflowLineageService.taskDependentMsg reports that other tasks — sub-workflow or dependent task types in other workflows — reference this workflow. Deleting would break those dependents, so deletion is refused with the dependent-task message appended.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/WorkflowDefinitionServiceImpl.java:867

            throw new ServiceException(Status.WORKFLOW_DEFINE_STATE_ONLINE, workflowDefinition.getName());
        }

        // check workflow instances is already running
        List<WorkflowInstanceSummaryDto> workflowInstances =
                workflowInstanceService.queryByWorkflowDefinitionCodeAndStatus(
                        workflowDefinition.getCode(), WorkflowExecutionStatus.NOT_TERMINAL_STATES);
        if (CollectionUtils.isNotEmpty(workflowInstances)) {
            throw new ServiceException(Status.DELETE_WORKFLOW_DEFINITION_EXECUTING_FAIL, workflowInstances.size());
        }

        // check workflow used by other task, including sub workflow and dependent task type
        Optional<String> taskDepMsg = workflowLineageService.taskDependentMsg(loginUser,
                workflowDefinition.getProjectCode(), workflowDefinition.getCode(), 0);

        if (taskDepMsg.isPresent()) {
            String errorMeg = "workflow definition cannot be deleted because it has dependent, " + taskDepMsg.get();
            log.error(errorMeg);
            throw new ServiceException(errorMeg);
        }
    }

    public void deleteWorkflowDefinitionByCode(User loginUser, long code) {
        WorkflowDefinition workflowDefinition = workflowDefinitionDao.queryByCode(code)
                .orElseThrow(() -> new ServiceException(WORKFLOW_DEFINITION_NOT_EXIST, String.valueOf(code)));

        Project project = projectDao.queryByCode(workflowDefinition.getProjectCode());
        projectService.checkHasProjectWritePermissionThrowException(loginUser, project);

        // Determine if the login user is the owner of the workflow definition
        if (loginUser.getId() != workflowDefinition.getUserId() && loginUser.getUserType() != UserType.ADMIN_USER) {
            throw new ServiceException(Status.USER_NO_OPERATION_PERM);
        }

        workflowDefinitionUsedInOtherTaskValid(loginUser, workflowDefinition);

        // get the timing according to the workflow definition

View on GitHub (pinned to 02eac45a1b)

Solutions

1. Read the dependent-task message to find which workflows/tasks reference this one.
2. Remove or re-point the DEPENDENT / SUB_WORKFLOW tasks that reference it, then delete again.
3. Delete the referencing parent workflows first if they are also being retired.

Example fix

// before
service.deleteWorkflowDefinitionByCode(loginUser, childCode); // has dependents
// after
Optional<String> dep = workflowLineageService.taskDependentMsg(loginUser, projectCode, childCode, 0);
if (dep.isPresent()) {
    // update or delete the dependent tasks listed in dep.get() first
}
service.deleteWorkflowDefinitionByCode(loginUser, childCode);

Optional<String> dep = workflowLineageService.taskDependentMsg(user, projectCode, code, 0);
if (dep.isPresent()) {
    throw new IllegalStateException("remove dependents first: " + dep.get());
}

try { service.deleteWorkflowDefinitionByCode(user, code); }
catch (ServiceException e) { /* parse dependent task list from e.getMessage() and remove those references */ }

When it happens

Trigger: Deleting a workflow that is used as a sub-workflow or referenced by a DEPENDENT task in another workflow in the same project (or cross-project, per lineage check).

Common situations: Retiring a shared child workflow that many parent workflows call; refactoring without updating dependent tasks; tenant/project merges leaving cross references.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• 10105
• SubWorkflowDefinition {subWorkflowDefinition name} is not on
• The releaseState {releaseState} is illegal, please check it.
• taskDepMsg.get()
• 1400004

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