conductor-oss/conductor · error · TransientException
Failed to get workflow: %s
Error message
Failed to get workflow: %s
What it means
getWorkflow wraps any com.datastax.driver.core.exceptions.DriverException in a TransientException. DriverExceptions denote cluster-side or connectivity failures (timeouts, unavailable nodes, read failures) that are expected to succeed on retry, so the framework RetryTemplate retries this up to 3 times with no backoff (ConductorCoreConfiguration). If retries are exhausted the exception propagates.
Source
Thrown at cassandra-persistence/src/main/java/com/netflix/conductor/cassandra/dao/CassandraExecutionDAO.java:568
Optional.ofNullable(resultSet.one())
.map(
row -> {
WorkflowModel wf =
readValue(
row.getString(PAYLOAD_KEY),
WorkflowModel.class);
recordCassandraDaoRequests(
"getWorkflow", "n/a", wf.getWorkflowName());
return wf;
})
.orElse(null);
}
return workflow;
} catch (DriverException e) {
Monitors.error(CLASS_NAME, "getWorkflow");
String errorMsg = String.format("Failed to get workflow: %s", workflowId);
LOGGER.error(errorMsg, e);
throw new TransientException(errorMsg);
}
}
/**
* This is a dummy implementation and this feature is not implemented for Cassandra backed
* Conductor
*/
@Override
public List<String> getRunningWorkflowIds(String workflowName, int version) {
throw new UnsupportedOperationException(
"This method is not implemented in CassandraExecutionDAO. Please use ExecutionDAOFacade instead.");
}
/**
* This is a dummy implementation and this feature is not implemented for Cassandra backed
* Conductor
*/
@OverrideView on GitHub (pinned to cf7c3e4a8a)
Solutions
- Confirm the Cassandra cluster is healthy and the requested consistency level is satisfiable by live replicas.
- Tune the DataStax driver connection pool / timeouts (cassandra.properties) and ensure RF >= nodes required for the read consistency.
- Rely on the built-in RetryTemplate; if exhaustion recurs, investigate the underlying DriverException cause logged at error.
- For chronic timeouts, scale the cluster or lower read consistency (after evaluating correctness).
Defensive patterns
Strategy: retry
Try / catch
// The framework RetryTemplate already retries TransientException 3x.
// For direct calls, mirror that contract:
int max = 3;
for (int attempt = 1; attempt <= max; attempt++) {
try {
return executionDAO.getWorkflow(workflowId, includeTasks);
} catch (TransientException e) {
if (attempt == max) throw e;
LOGGER.warn("getWorkflow attempt {} failed, retrying", attempt, e);
}
} Prevention
- Tune the DataStax driver connection pool and read timeouts to the cluster's latency profile.
- Ensure RF and read consistency are compatible with expected node loss.
- Monitor Cassandra node health and GC, and alert on DriverException rates.
When it happens
Trigger: Any getWorkflow / getWorkflowById read hitting a DriverException: node down, read timeout, consistency level not met, connection pool exhaustion, or network partition to Cassandra.
Common situations: Cassandra cluster under load or losing nodes; RF/consistency misconfiguration; driver connection pool too small for concurrency; GC stalls on Cassandra nodes.
Related errors
- Failed to add event execution for event: %s, handler: %s
- Failed to update event execution for event: %s, handler: %s
- Failed to remove event execution for event: %s, handler: %s
- Failed to fetch event executions for event: %s, handler: %s
- Error updating taskDefLimit for task - %s:%s in workflow: %s
AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14).
Data as JSON: /api/errors/dc7a7ab9932f9f58.
Report an issue: GitHub.