What causes "Error acquiring lock when creating workflow: {}" in conductor-oss/conductor?

Retry the startWorkflowIdempotent call after a short backoff — the TransientException signals the lock is temporarily unavailable.

conductor-oss/conductor · warning · TransientException

Error acquiring lock when creating workflow: {}

Error message

Error acquiring lock when creating workflow: {}

What it means

Thrown by startWorkflowIdempotent() when executionLockService.acquireLock(workflowId) returns false. The lock prevents concurrent idempotent starts from racing on the same workflowId — two callers creating the same workflow ID simultaneously would corrupt state. Since lock acquisition failure is temporary (another holder may release), this is a TransientException signaling 'retry later'. Note: the message literal '{}' is an unformatted SLF4J placeholder, not a bug in your input.

Source

Thrown at core/src/main/java/com/netflix/conductor/core/execution/WorkflowExecutorOps.java:2639

                executionDAOFacade.removeWorkflow(workflowId, false);
            } catch (Exception rwe) {
                LOGGER.error("Could not remove the workflowId: " + workflowId, rwe);
            }
            throw e;
        }
    }

    @Override
    public WorkflowModel startWorkflowIdempotent(StartWorkflowInput input) {
        Preconditions.checkArgument(
                StringUtils.isNotBlank(input.getWorkflowId()),
                "workflowId must be present for idempotent workflow start");

        WorkflowDef workflowDefinition = resolveWorkflowDefinition(input);
        String workflowId = input.getWorkflowId();

        if (!executionLockService.acquireLock(workflowId)) {
            throw new TransientException("Error acquiring lock when creating workflow: {}");
        }

        boolean createAttempted = false;
        try {
            try {
                WorkflowModel existingWorkflow =
                        executionDAOFacade.getWorkflowModelFromExecutionDAO(workflowId, false);
                validateIdempotentWorkflowOwnership(input, existingWorkflow);
                return existingWorkflow;
            } catch (NotFoundException e) {
                LOGGER.debug(
                        "No existing workflow found in execution store for idempotent start of workflow id {}, proceeding with creation",
                        workflowId);
            }

            WorkflowModel workflow = createWorkflowModel(input, workflowDefinition, workflowId);
            createAttempted = true;
            createAndQueueEvaluationWithLock(workflow);

View on GitHub (pinned to cf7c3e4a8a)

Solutions

Retry the startWorkflowIdempotent call after a short backoff — the TransientException signals the lock is temporarily unavailable.
Verify the lock service backend (Redis/DynamoDB) is healthy and has capacity.
Check for orphaned locks from crashed nodes — increase lock TTL to exceed typical workflow creation latency.
Reduce concurrent idempotent start calls for the same workflowId by deduplicating at the client layer.

Example fix

// before
workflowExecutor.startWorkflowIdempotent(input);

// after
int maxRetries = 3;
for (int i = 0; i <= maxRetries; i++) {
    try {
        return workflowExecutor.startWorkflowIdempotent(input);
    } catch (TransientException e) {
        if (i == maxRetries) throw e;
        Thread.sleep(200L * (i + 1));
    }
}

Defensive patterns

Strategy: retry

Try / catch

try {
    workflowExecutor.startWorkflowIdempotent(input);
} catch (TransientException e) {
    // Lock temporarily unavailable — retry with backoff
    Thread.sleep(retryDelayMs);
    workflowExecutor.startWorkflowIdempotent(input);
}

Prevention

Wrap idempotent start calls in a retry loop with exponential backoff for TransientException.
Monitor lock service health (Redis/DynamoDB) to detect contention early.
Deduplicate idempotent start requests at the client layer to reduce lock contention.

When it happens

Trigger: Two concurrent startWorkflowIdempotent calls with the same workflowId. The lock service (typically Redis or DynamoDB-based) is unreachable, saturated, or the lock is held by a previous start attempt that has not yet released it. High-throughput idempotent starts under contention.

Common situations: Load balancer retrying an idempotent start while the original request is still processing. Lock TTL shorter than workflow creation time, causing the lock to expire and be re-acquired by a different thread while the first is still creating. Redis connectivity issues degrading the lock service.

Related errors

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