conductor-oss/conductor · error · UnsupportedOperationException

This method is not implemented in CassandraExecutionDAO. Ple

Error message

This method is not implemented in CassandraExecutionDAO. Please use ExecutionDAOFacade instead.

What it means

Thrown deliberately by CassandraExecutionDAO.getTasks(String taskType, String startKey, int count). It is an UnsupportedOperationException, not a runtime fault — the method is a dummy stub because querying in-progress tasks by type with paging is not implemented for Cassandra-backed Conductor. The message directs callers to ExecutionDAOFacade, which orchestrates cache + DAO lookups instead.

Source

Thrown at cassandra-persistence/src/main/java/com/netflix/conductor/cassandra/dao/CassandraExecutionDAO.java:176

                        .setConsistencyLevel(properties.getWriteConsistencyLevel());
    }

    @Override
    public List<TaskModel> getPendingTasksByWorkflow(String taskName, String workflowId) {
        List<TaskModel> tasks = getTasksForWorkflow(workflowId);
        return tasks.stream()
                .filter(task -> taskName.equals(task.getTaskType()))
                .filter(task -> TaskModel.Status.IN_PROGRESS.equals(task.getStatus()))
                .collect(Collectors.toList());
    }

    /**
     * This is a dummy implementation and this feature is not implemented for Cassandra backed
     * Conductor
     */
    @Override
    public List<TaskModel> getTasks(String taskType, String startKey, int count) {
        throw new UnsupportedOperationException(
                "This method is not implemented in CassandraExecutionDAO. Please use ExecutionDAOFacade instead.");
    }

    /**
     * Inserts tasks into the Cassandra datastore. <b>Note:</b> Creates the task_id to workflow_id
     * mapping in the task_lookup table first. Once this succeeds, inserts the tasks into the
     * workflows table. Tasks belonging to the same shard are created using batch statements.
     *
     * @param tasks tasks to be created
     */
    @Override
    public List<TaskModel> createTasks(List<TaskModel> tasks) {
        validateTasks(tasks);
        String workflowId = tasks.get(0).getWorkflowInstanceId();
        UUID workflowUUID = toUUID(workflowId, "Invalid workflow id");
        try {
            WorkflowMetadata workflowMetadata = getWorkflowMetadata(workflowId);
            int totalTasks = workflowMetadata.getTotalTasks() + tasks.size();

View on GitHub (pinned to cf7c3e4a8a)

Solutions

  1. Route the call through ExecutionDAOFacade.getTasks(...) instead of the raw CassandraExecutionDAO.
  2. If you maintain custom scheduling code, inject ExecutionDAOFacade rather than the ExecutionDAO.
  3. Keep the stub in mind: features relying on type-keyed task listing are unsupported on Cassandra — use a supported persistence backend if the feature is required.

Example fix

// before
cassandraExecutionDao.getTasks(taskType, startKey, count);

// after
executionDAOFacade.getTasks(taskType, startKey, count);
Defensive patterns

Strategy: validation

Validate before calling

// Never call the raw Cassandra DAO for this operation; detect and route via the facade
if (dao instanceof CassandraExecutionDAO) {
    throw new UnsupportedOperationException("Use ExecutionDAOFacade.getTasks on Cassandra");
}

Type guard

static boolean supportsGetTasksByType(ExecutionDAO dao) {
    return !(dao instanceof CassandraExecutionDAO);
}

Try / catch

try {
    dao.getTasks(type, start, count);
} catch (UnsupportedOperationException e) {
    log.warn("Raw DAO unsupported; routing through ExecutionDAOFacade");
    return facade.getTasks(type, start, count);
}

Prevention

When it happens

Trigger: Calling CassandraExecutionDAO.getTasks(taskType, startKey, count) directly. Any code path that invokes the raw ExecutionDAO.getTasks on the Cassandra implementation rather than going through ExecutionDAOFacade.

Common situations: Custom code or a plugin that obtained the Cassandra ExecutionDAO bean directly and called getTasks. A poll/sweep routine that was written against the Redis or in-memory DAO and reused against Cassandra. Migrating a deployment to Cassandra without updating direct DAO callers.

Related errors


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