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
     */
    @Override

View on GitHub (pinned to cf7c3e4a8a)

Solutions

  1. Confirm the Cassandra cluster is healthy and the requested consistency level is satisfiable by live replicas.
  2. Tune the DataStax driver connection pool / timeouts (cassandra.properties) and ensure RF >= nodes required for the read consistency.
  3. Rely on the built-in RetryTemplate; if exhaustion recurs, investigate the underlying DriverException cause logged at error.
  4. 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

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


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