apache/dolphinscheduler · error · ServiceException

NO_CURRENT_OPERATING_PERMISSION

NO_CURRENT_OPERATING_PERMISSION

Error message

NO_CURRENT_OPERATING_PERMISSION

What it means

Raised in MonitorServiceImpl.queryWorkflowExecutors when the logged-in user is not an ADMIN_USER. Viewing workflow executors on a master server is an admin-only monitoring capability, so non-admin callers are rejected with NO_CURRENT_OPERATING_PERMISSION.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/MonitorServiceImpl.java:78

     * query database state
     *
     * @param loginUser login user
     * @return data base state
     */
    @Override
    public List<DatabaseMetrics> queryDatabaseState(User loginUser) {
        return Lists.newArrayList(databaseMonitor.getDatabaseMetrics());
    }

    @Override
    public List<Server> listServer(RegistryNodeType nodeType) {
        return registryClient.getServerList(nodeType);
    }

    @Override
    public List<WorkflowExecutorDTO> queryWorkflowExecutors(User loginUser, String masterAddress) {
        if (!loginUser.getUserType().equals(UserType.ADMIN_USER)) {
            throw new ServiceException(Status.NO_CURRENT_OPERATING_PERMISSION);
        }

        WorkflowExecutorQueryResponse response = Clients
                .withService(IWorkflowExecutorQueryClient.class)
                .withHost(masterAddress)
                .queryWorkflowExecutors(new WorkflowExecutorQueryRequest());
        if (!response.isSuccess()) {
            throw new ServiceException(response.getMessage());
        }
        return response.getWorkflowExecutors();
    }

    @Override
    public List<TaskExecutorDTO> queryTaskExecutors(User loginUser, String serverAddress) {
        if (!loginUser.getUserType().equals(UserType.ADMIN_USER)) {
            throw new ServiceException(Status.NO_CURRENT_OPERATING_PERMISSION);
        }
        TaskExecutorQueryResponse response = Clients

View on GitHub (pinned to 02eac45a1b)

Solutions

  1. Log in as / use a token for an admin user (userType=ADMIN_USER).
  2. If the user should have access, elevate their type in the user management UI (Security > User Management).
  3. Restrict the integration to admin credentials or add a permission check in the client before calling.

Example fix

// before
List<WorkflowExecutorDTO> list = monitorService.queryWorkflowExecutors(normalUser, masterAddress);
// after
if (normalUser.getUserType() == UserType.ADMIN_USER) {
    List<WorkflowExecutorDTO> list = monitorService.queryWorkflowExecutors(normalUser, masterAddress);
}
Defensive patterns

Strategy: validation

Validate before calling

if (loginUser.getUserType() != UserType.ADMIN_USER) {
    throw new SecurityException("admin privileges required");
}

Type guard

boolean isAdmin(User user) {
    return user != null && user.getUserType() == UserType.ADMIN_USER;
}

Try / catch

try {
    List<WorkflowExecutorDTO> list = monitorService.queryWorkflowExecutors(loginUser, masterAddress);
} catch (ServiceException e) {
    // NO_CURRENT_OPERATING_PERMISSION - require admin
}

Prevention

When it happens

Trigger: Calling GET /monitor/master/list-workflow-executor (queryWorkflowExecutors) with a login user whose userType is GENERAL_USER rather than ADMIN_USER.

Common situations: Non-admin operator or automation token hitting the monitor endpoints; role changed on the account; API integration built assuming admin privileges.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

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