What causes "Error updating task: %s in workflow: %s" in conductor-oss/conductor?

Inspect the wrapped cause — most often an index or DAO connectivity error.

conductor-oss/conductor · error · TransientException

Error updating task: %s in workflow: %s

Error message

Error updating task: %s in workflow: %s

What it means

Catch-all TransientException thrown by updateTask when any Exception (other than TerminateWorkflowException, which is re-thrown) escapes the task-indexing / update block. The message carries taskId and workflowInstanceId. It means the task update did not complete (typically the index write failed) and the caller should treat it as retryable.

Source

Thrown at core/src/main/java/com/netflix/conductor/core/dal/ExecutionDAOFacade.java:583

            /*
             * Indexing a task for every update adds a lot of volume. That is ok but if async indexing
             * is enabled and tasks are stored in memory until a block has completed, we would lose a lot
             * of tasks on a system failure. So only index for each update if async indexing is not enabled.
             * If it *is* enabled, tasks will be indexed only when a workflow is in terminal state.
             */
            if (!properties.isAsyncIndexingEnabled() && properties.isTaskIndexingEnabled()) {
                indexDAO.indexTask(new TaskSummary(taskModel.toTask()));
            }
        } catch (TerminateWorkflowException e) {
            // re-throw it so we can terminate the workflow
            throw e;
        } catch (Exception e) {
            String errorMsg =
                    String.format(
                            "Error updating task: %s in workflow: %s",
                            taskModel.getTaskId(), taskModel.getWorkflowInstanceId());
            LOGGER.error(errorMsg, e);
            throw new TransientException(errorMsg, e);
        }
    }

    public void updateTasks(List<TaskModel> tasks) {
        tasks.forEach(this::updateTask);
    }

    public void removeTask(String taskId) {
        executionDAO.removeTask(taskId);
    }

    private void removeTaskIndex(WorkflowModel workflow, TaskModel task, boolean archiveTask)
            throws JsonProcessingException {
        if (!properties.isTaskIndexingEnabled()) {
            return;
        }
        if (archiveTask) {
            if (task.getStatus().isTerminal()) {

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Inspect the wrapped cause — most often an index or DAO connectivity error.
Retry the task update with backoff; ensure idempotency on the worker side so a retry does not duplicate state.
Consider enabling conductor.app.async-indexing-enabled=true to decouple task updates from synchronous index writes.
If payloads are large, raise the index max document size or trim task output.

Defensive patterns

Strategy: retry

Try / catch

try {
    executionDAOFacade.updateTask(taskModel);
} catch (TransientException e) {
    // task update/index failed; retry with backoff (ensure worker-side idempotency)
}

Prevention

Enable async indexing (conductor.app.async-indexing-enabled=true) to decouple task updates from index writes if synchronous indexing is fragile.
Make worker task updates idempotent so retries are safe.
Cap task output size to avoid index rejections.

When it happens

Trigger: A worker/decider calls updateTask and the synchronous indexDAO.indexTask(...) (when asyncIndexingEnabled=false and taskIndexingEnabled=true) throws, or the underlying executionDAO task update throws.

Common situations: Indexing disabled-async path hits an Elasticsearch outage. A task payload too large for the index. A connection pool exhaustion during a burst of task completions. Transient store failure mid-update.

Related errors

AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/5dd41fbf2a723918. Report an issue: GitHub.