apache/dolphinscheduler · error · ServiceException

1401001

1401001

Error message

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

What it means

Status.WORKER_GROUP_DEPENDENT_SCHEDULER_EXISTS (1401001) is thrown by checkWorkerGroupDependencies when one or more schedule (workflow timing) records still target the worker group. Deletion is blocked and the message lists the count plus up to three dependent workflow definition names.

Source

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

        // 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>()
                        .lambda().eq(EnvironmentWorkerGroupRelation::getWorkerGroup, workerGroup.getName()));

        if (CollectionUtils.isNotEmpty(environmentWorkerGroupRelations)) {
            throw new ServiceException(Status.WORKER_GROUP_DEPENDENT_ENVIRONMENT_EXISTS,
                    environmentWorkerGroupRelations.size());
        }
    }

    private void checkWorkerGroupAddrList(String workerGroupAddress) {
        if (Strings.isNullOrEmpty(workerGroupAddress)) {
            return;
        }

View on GitHub (pinned to 02eac45a1b)

Solutions

Edit each listed workflow's timing/schedule and switch it to another worker group, then retry deletion.
Or take the dependent schedules offline and delete them if they're no longer needed.
Enumerate dependencies beforehand with scheduleDao.queryScheduleByWorkerGroup(groupName) to get the full list.
After all schedules are repointed or removed, re-run deleteWorkerGroupById.

Example fix

// before
workerGroupService.deleteWorkerGroupById(loginUser, 7); // schedules still use group
// after
List<Schedule> scheds = scheduleDao.queryScheduleByWorkerGroup("legacy");
scheds.forEach(s -> updateScheduleWorkerGroup(s.getId(), "default"));
workerGroupService.deleteWorkerGroupById(loginUser, 7);

Defensive patterns

Strategy: validation

Validate before calling

List<Schedule> scheds = scheduleDao.queryScheduleByWorkerGroup(groupName);
if (!scheds.isEmpty()) {
    throw new IllegalStateException("repoint " + scheds.size() + " schedules before delete");
}

Try / catch

try {
    workerGroupService.deleteWorkerGroupById(loginUser, id);
} catch (ServiceException e) {
    if (e.getCode() == 1401001) {
        // workflow names are in the message; edit each timing then retry
    }
}

Prevention

Audit schedules referencing a group before decommissioning it
Repoint or take offline schedules during worker-group migrations
Combine with task-dependency checks (1401000) in one pre-flight
Re-run deletion only after all listed workflows are rescheduled

When it happens

Trigger: Attempting deleteWorkerGroupById while any schedule in t_ds_schedules has the group as its worker group — e.g. online (committed) workflow schedules still pinned to the group.

Common situations: Deleting a group whose workflows are still scheduled to run on it; cloned workflows whose schedules inherited the group; decommissioning workers before rescheduling the workflows.

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/bf9ebed938545f6a. Report an issue: GitHub.