apache/dolphinscheduler · error · ServiceException

10165

10165

Error message

force task success error

What it means

Status.FORCE_TASK_SUCCESS_ERROR, thrown when the DAO update persisting FORCED_SUCCESS state on the task instance returns false (no row updated). The validation passed and the state was set in memory, but the database write did not change any row, indicating the instance row vanished or a concurrency race modified it.

Source

Thrown at dolphinscheduler-api/src/main/java/org/apache/dolphinscheduler/api/service/impl/TaskInstanceServiceImpl.java:225

        WorkflowInstance workflowInstance = workflowInstanceDao.queryOptionalById(task.getWorkflowInstanceId())
                .orElseThrow(
                        () -> new ServiceException(Status.WORKFLOW_INSTANCE_NOT_EXIST, task.getWorkflowInstanceId()));
        if (!workflowInstance.getState().isFinalState()) {
            throw new ServiceException("The workflow instance is not finished: " + workflowInstance.getState()
                    + " cannot force start task instance");
        }

        // check whether the task instance state type is failure or cancel
        if (!task.getState().isFailure() && !task.getState().isKill()) {
            throw new ServiceException(Status.TASK_INSTANCE_STATE_OPERATION_ERROR, taskInstanceId, task.getState());
        }

        // change the state of the task instance
        task.setState(TaskExecutionStatus.FORCED_SUCCESS);
        task.setEndTime(new Date());
        boolean changed = taskInstanceDao.updateById(task);
        if (!changed) {
            throw new ServiceException(Status.FORCE_TASK_SUCCESS_ERROR);
        }
        processService.forceWorkflowInstanceSuccessByTaskInstanceId(task);
        log.info("Force success task instance id: {} success", taskInstanceId);
    }

    @Override
    public Result taskSavePoint(User loginUser, long projectCode, Integer taskInstanceId) {
        Result result = new Result();

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

        TaskInstance taskInstance = taskInstanceDao.queryById(taskInstanceId);
        if (taskInstance == null || taskInstance.getProjectCode() != projectCode) {
            log.error("Task definition can not be found, projectCode:{}, taskInstanceId:{}.", projectCode,
                    taskInstanceId);
            putMsg(result, Status.TASK_INSTANCE_NOT_FOUND);
            return result;

View on GitHub (pinned to 02eac45a1b)

Solutions

  1. Refresh the task instance and retry once — the first update may have already applied (check state == FORCED_SUCCESS).
  2. Check server logs around the time for concurrent modifications or deletes of the task instance.
  3. Verify the task instance still exists in the DB (t_ds_task_instance) with the given id.
  4. If it recurs, serialize force-success operations per task (lock or UI dedup) and check database connectivity.

Example fix

// before
boolean changed = taskInstanceDao.updateById(task);
if (!changed) { throw new ServiceException(Status.FORCE_TASK_SUCCESS_ERROR); }
// after
boolean changed = taskInstanceDao.updateById(task);
if (!changed) {
    TaskInstance fresh = taskInstanceDao.queryById(task.getId());
    if (fresh == null || fresh.getState() != TaskExecutionStatus.FORCED_SUCCESS) {
        throw new ServiceException(Status.FORCE_TASK_SUCCESS_ERROR);
    }
}
Defensive patterns

Strategy: retry

Validate before calling

// pre-check that the row still exists before update
if (taskInstanceDao.queryOptionalById(id).isEmpty()) {
    throw new IllegalStateException("task instance " + id + " no longer exists");
}

Try / catch

try {
    taskInstanceService.forceTaskSuccess(loginUser, projectCode, id);
} catch (ServiceException e) {
    if (e.getCode() == 10165) {
        // re-read the task; if already FORCED_SUCCESS, treat as success, else retry once
    }
}

Prevention

When it happens

Trigger: taskInstanceDao.updateById(task) returns false — typically the task instance row was deleted by another process between read and update, or an optimistic/concurrent update overwrote it so the update affected 0 rows.

Common situations: Two operators click force-success simultaneously; a cleanup job purges old task instances while an admin is force-succeeding them; DB connectivity issues surfaced as zero-row updates.

Related errors


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