conductor-oss/conductor · error · TransientException

Error removing workflow: {}

Error message

Error removing workflow: {}

What it means

Catch-all TransientException thrown by removeWorkflowWithExpiry when any unexpected Exception escapes its body (after recording Monitors.recordDaoError('executionDao','removeWorkflow')). It signals the removal did not complete but is likely retryable — the wrapped exception holds the real cause. Index NotFoundException is handled separately above this catch, so this fires only for other failures.

Source

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

            String workflowId, boolean archiveWorkflow, int ttlSeconds) {
        try {
            WorkflowModel workflow = getWorkflowModelFromDataStore(workflowId, true);

            try {
                removeWorkflowIndex(workflow, archiveWorkflow);
            } catch (NotFoundException e) {
                if (archiveWorkflow) {
                    throw e;
                }
                // Idempotent deletion: missing index records should not block DAO removal.
                LOGGER.info(
                        "Workflow {} not found in index during removal, continuing", workflowId, e);
            }
            // remove workflow from DAO with TTL
            executionDAO.removeWorkflowWithExpiry(workflowId, ttlSeconds);
        } catch (Exception e) {
            Monitors.recordDaoError("executionDao", "removeWorkflow");
            throw new TransientException("Error removing workflow: " + workflowId, e);
        }
    }

    /**
     * Reset the workflow state by removing from the {@link ExecutionDAO} and removing this workflow
     * from the {@link IndexDAO}.
     *
     * @param workflowId the workflow id to be reset
     */
    public void resetWorkflow(String workflowId) {
        getWorkflowModelFromDataStore(workflowId, true);
        executionDAO.removeWorkflow(workflowId);
        try {
            if (properties.isAsyncIndexingEnabled()) {
                indexDAO.asyncRemoveWorkflow(workflowId);
            } else {
                indexDAO.removeWorkflow(workflowId);
            }

View on GitHub (pinned to cf7c3e4a8a)

Solutions

1. Inspect the wrapped cause in the stack trace to identify the failing store.
2. If transient (network/timeout), the sweeper or a manual retry will succeed on the next pass — the workflow is still in the DAO.
3. Check store connectivity, connection-pool sizing, and timeouts.
4. If it persists, verify the TTL removal is supported by the configured ExecutionDAO implementation.

try {
    executionDAOFacade.removeWorkflowWithExpiry(workflowId, archive, ttl);
} catch (TransientException e) {
    // underlying store failed; safe to retry, workflow still present in DAO
}

When it happens

Trigger: The ExecutionDAO.removeWorkflowWithExpiry or the index removal throws a connectivity/timeout error, or an underlying store returns an unexpected exception during the TTL-based removal path.

Common situations: Database (Redis/Postgres/DynamoDB) temporarily unreachable during a sweep. A lock contention failure. Transient network blip to the index. Triggered by the sweeper's periodic removal of expired workflows.

Related errors

• Error resetting workflow state: {}
• Error creating workflow: %s
• Failed to update workflow: %s
• Failed to remove workflow: %s
• No such workflow found by id: %s

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