apache/dolphinscheduler · error · ServiceException

The workflow instance is not finished: {workflowInstanceStat

Error message

The workflow instance is not finished: {workflowInstanceState} cannot force start task instance

What it means

Thrown by TaskInstanceServiceImpl.forceTaskSuccess when the parent workflow instance is still running (its state is not a final state). Force-success is only permitted once the enclosing workflow has finished; otherwise dependent bookkeeping (e.g. forceWorkflowInstanceSuccessByTaskInstanceId) would be inconsistent. The message embeds the current workflow state so you can see why it was rejected.

Source

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

     * @return the result code and msg
     */
    @Transactional
    @Override
    public void forceTaskSuccess(User loginUser, long projectCode, Integer taskInstanceId) {
        projectService.checkHasProjectWritePermissionThrowException(loginUser, projectCode);

        TaskInstance task = taskInstanceDao.queryOptionalById(taskInstanceId)
                .orElseThrow(() -> new ServiceException(Status.TASK_INSTANCE_NOT_FOUND));

        if (task.getProjectCode() != projectCode) {
            throw new ServiceException("The task instance is not under the project: " + projectCode);
        }

        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);
    }

View on GitHub (pinned to 02eac45a1b)

Solutions

  1. Wait until the workflow instance reaches a final state (SUCCESS/FAILURE/STOP/KILL) before calling force-task-success.
  2. If the workflow should be stopped first, stop/kill the workflow instance, then force-success the task.
  3. Poll the workflow instance state endpoint until isFinalState before retrying.
  4. If you really need to modify a running workflow, use the workflow-level stop/pause operations instead.

Example fix

// before
forceSuccess(taskInstanceId); // workflow still RUNNING -> 301
// after
WorkflowInstance wf = getWorkflowInstance(taskInstanceId);
if (wf.getState().isFinalState()) {
    forceSuccess(taskInstanceId);
} else {
    stopWorkflowInstance(wf.getId());
}
Defensive patterns

Strategy: validation

Validate before calling

WorkflowInstance wf = workflowInstanceDao.queryOptionalById(task.getWorkflowInstanceId()).orElse(null);
if (wf == null || !wf.getState().isFinalState()) {
    throw new IllegalStateException("wait for workflow to finish before force-success");
}

Type guard

boolean forceSuccessAllowed(WorkflowInstance wf) { return wf != null && wf.getState() != null && wf.getState().isFinalState(); }

Try / catch

try {
    taskInstanceService.forceTaskSuccess(loginUser, projectCode, id);
} catch (ServiceException e) {
    if (e.getMessage().startsWith("The workflow instance is not finished")) {
        // schedule retry after workflow reaches final state
    }
}

Prevention

When it happens

Trigger: POSTing force-task-success for a task whose workflow instance state isRunning/isReadyPause/etc. (any non-final state such as RUNNING_EXECUTION, WAITING_THREAD, READY_STOP).

Common situations: Users try to 'unstick' a running workflow by force-succeeding one failed task; schedulers retry the call while the workflow is still active; kill is in progress so state is not yet final.

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