apache/dolphinscheduler · error · ServiceException

1401000

1401000

Error message

You can not modify or remove this worker group, cause it has [{0}] dependent tasks like :{1}

What it means

Status.WORKER_GROUP_DEPENDENT_TASK_EXISTS (1401000) is thrown by checkWorkerGroupDependencies (invoked from deleteWorkerGroupById and group modification paths) when task definitions still reference the worker group. The message includes the count of dependent tasks and a JSON array of up to three example task names, so deletion is blocked until those references are removed.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/WorkerGroupServiceImpl.java:166

            boardCastToMasterThatWorkerGroupChanged();
            return workerGroup;
        } catch (DuplicateKeyException duplicateKeyException) {
            throw new ServiceException(Status.NAME_EXIST, name);
        }
    }

    /**
     * check if the worker group has any dependent tasks, schedulers or environments;
     * throws ServiceException with the matching status if any dependency is found.
     */
    private void checkWorkerGroupDependencies(WorkerGroup workerGroup) {
        // check if the worker group has any dependent tasks
        List<TaskDefinition> taskDefinitions = taskDefinitionDao.queryByWorkerGroup(workerGroup.getName());

        if (CollectionUtils.isNotEmpty(taskDefinitions)) {
            List<String> taskNames = taskDefinitions.stream().limit(3).map(TaskDefinition::getName)
                    .collect(Collectors.toList());
            throw new ServiceException(Status.WORKER_GROUP_DEPENDENT_TASK_EXISTS, taskDefinitions.size(),
                    JSONUtils.toJsonString(taskNames));
        }

        // check if the worker group has any dependent schedulers
        List<Schedule> schedules = scheduleDao.queryScheduleByWorkerGroup(workerGroup.getName());

        if (CollectionUtils.isNotEmpty(schedules)) {
            List<String> workflowDefinitionNames = schedules.stream().limit(3)
                    .map(schedule -> workflowDefinitionDao.queryByCode(schedule.getWorkflowDefinitionCode())
                            .orElse(null).getName())
                    .collect(Collectors.toList());
            throw new ServiceException(Status.WORKER_GROUP_DEPENDENT_SCHEDULER_EXISTS, schedules.size(),
                    JSONUtils.toJsonString(workflowDefinitionNames));
        }

        // check if the worker group has any dependent environments
        List<EnvironmentWorkerGroupRelation> environmentWorkerGroupRelations =
                environmentWorkerGroupRelationMapper.selectList(new QueryWrapper<EnvironmentWorkerGroupRelation>()

View on GitHub (pinned to 02eac45a1b)

Solutions

Reassign all task definitions that use this worker group to another group (edit each workflow task, or batch-update via the API/DB).
Use the taskNames list in the message to locate at least the first three offending tasks.
Query taskDefinitionDao.queryByWorkerGroup(groupName) (or equivalent API) to enumerate all dependent tasks before deleting.
If the group is truly obsolete, delete/repoint dependent tasks first, then retry the deletion.
Consider deleting the tasks/workflows that are no longer needed.

Example fix

// before
workerGroupService.deleteWorkerGroupById(loginUser, 5); // 3 tasks still use group 'legacy'
// after
List<TaskDefinition> deps = taskDefinitionDao.queryByWorkerGroup("legacy");
deps.forEach(t -> updateTaskWorkerGroup(t.getCode(), "default")); // reassign first
workerGroupService.deleteWorkerGroupById(loginUser, 5);

Defensive patterns

Strategy: validation

Validate before calling

List<TaskDefinition> deps = taskDefinitionDao.queryByWorkerGroup(groupName);
if (!deps.isEmpty()) {
    throw new IllegalStateException("reassign " + deps.size() + " dependent tasks before delete");
}

Try / catch

try {
    workerGroupService.deleteWorkerGroupById(loginUser, id);
} catch (ServiceException e) {
    if (e.getCode() == 1401000) {
        // parse taskNames from message, reassign those tasks, then retry
    }
}

Prevention

Run dependency checks before planned deletions
Repoint task definitions to a surviving group during migrations
Search cloned workflows for the old group name after copying
Keep a 'default' fallback group for task reassignment

When it happens

Trigger: Deleting (or otherwise modifying) a worker group while any t_ds_task_definition row has that worker group assigned; the check runs before deleteWorkerGroupById performs the removal.

Common situations: Retiring a worker group that is still the default in many task definitions; environment migrations where workflows were cloned with the old group name; forgetting that copied workflows keep the original worker group setting.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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