apache/dolphinscheduler · error · ServiceException

DATA_IS_NULL

DATA_IS_NULL

Error message

DATA_IS_NULL: data {0} can not be null

What it means

The queryTopNLongestRunningWorkflowInstance API validates its time parameters before querying workflow instance statistics. When the startTime request parameter is null, it throws ServiceException with Status.DATA_IS_NULL and the message template 'data {0} can not be null' where {0} is substituted with 'startTime'. This guards the subsequent DateUtils.stringToDate conversion from a null input.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/WorkflowInstanceServiceImpl.java:185

    @Autowired
    private TaskDatasourcePermissionChecker taskDatasourcePermissionChecker;

    @Autowired
    private TaskSubWorkflowPermissionChecker taskSubWorkflowPermissionChecker;

    @Override
    public List<WorkflowInstanceSummaryVO> queryTopNLongestRunningWorkflowInstance(User loginUser, long projectCode,
                                                                                   int size,
                                                                                   String startTime, String endTime) {
        Project project = projectDao.queryByCode(projectCode);
        // check user access for project
        projectService.checkProjectAndAuthThrowException(loginUser, project, WORKFLOW_INSTANCE);

        if (0 > size) {
            throw new ServiceException(Status.NEGTIVE_SIZE_NUMBER_ERROR, size);
        }
        if (Objects.isNull(startTime)) {
            throw new ServiceException(Status.DATA_IS_NULL, Constants.START_TIME);
        }
        Date start = DateUtils.stringToDate(startTime);
        if (Objects.isNull(endTime)) {
            throw new ServiceException(Status.DATA_IS_NULL, Constants.END_TIME);
        }
        Date end = DateUtils.stringToDate(endTime);
        if (start == null || end == null) {
            throw new ServiceException(Status.REQUEST_PARAMS_NOT_VALID_ERROR, Constants.START_END_DATE);
        }
        if (start.getTime() > end.getTime()) {
            throw new ServiceException(Status.START_TIME_BIGGER_THAN_END_TIME_ERROR, startTime, endTime);
        }

        return workflowInstanceDao.queryTopNWorkflowInstance(size, start, end, WorkflowExecutionStatus.SUCCESS,
                projectCode)
                .stream()
                .map(WorkflowInstanceSummaryVO::fromSummaryDto)
                .collect(Collectors.toList());

View on GitHub (pinned to 02eac45a1b)

Solutions

1. Pass a valid startTime query parameter in 'yyyy-MM-dd HH:mm:ss' format (e.g. 2024-01-01 00:00:00).
2. Fix the frontend/scheduler caller so it always sends both startTime and endTime for the top-N query.
3. If calling the service programmatically, check Objects.isNull(startTime) before invoking the method.

Example fix

// before
githubApi.queryTopNLongestRunningWorkflowInstance(loginUser, project, size, null, endTime);
// after
String startTime = "2024-01-01 00:00:00";
githubApi.queryTopNLongestRunningWorkflowInstance(loginUser, project, size, startTime, endTime);

// client-side pre-check
if (startTime == null || startTime.isEmpty()) {
    throw new IllegalArgumentException("startTime is required (format: yyyy-MM-dd HH:mm:ss)");
}

function hasStartTime(p: { startTime?: string }): p is { startTime: string } {
  return typeof p.startTime === 'string' && p.startTime.length > 0;
}

try {
    // top-N query
} catch (ServiceException e) {
    if (e.getCode() == Status.DATA_IS_NULL.getCode()) {
        // prompt user / default startTime, e.g. 7 days ago
    } else throw e;
}

When it happens

Trigger: Calling GET /projects/{projectName}/workflow-instances/top-N (queryTopNLongestRunningWorkflowInstance) while omitting the startTime query parameter or passing it as an empty/absent value.

Common situations: Frontend clients building the statistics page forget the startTime query param; API consumers scripting against the endpoint omit optional-looking time fields; Swagger/Postman calls executed with default parameter sets that leave startTime blank.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

• REQUEST_PARAMS_NOT_VALID_ERROR
• PLUGIN_INSTANCE_ALREADY_EXISTS
• REQUEST_PARAMS_NOT_VALID_ERROR
• 1400004
• The task instance is not under the project: {projectCode}

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