apache/seatunnel · error · JobDefineCheckException

No source tables were available after discovery. Check sourc

Error message

No source tables were available after discovery. Check source-side failed-table warnings for details.

What it means

Thrown by MultipleTableJobConfigParser.parse() when the job config declares source tables but after catalog discovery no source table yielded any reader actions. SeaTunnel ran in multi-table failure tolerance mode (continue on failed tables), every source table failed discovery, so nothing remains to build the DAG from. It is a job-definition validation error raised before job execution.

Source

Thrown at seatunnel-engine/seatunnel-engine-core/src/main/java/org/apache/seatunnel/engine/core/parse/MultipleTableJobConfigParser.java:275

            if (isStartWithSavePoint
                    && pipelineCheckpoints != null
                    && !pipelineCheckpoints.isEmpty()) {
                Preconditions.checkState(
                        sourceConfigs.size() == pipelineCheckpoints.size(),
                        "The number of source configurations and pipeline checkpoints must be equal.");
            }
            for (int configIndex = 0; configIndex < sourceConfigs.size(); configIndex++) {
                Config sourceConfig = sourceConfigs.get(configIndex);
                Tuple2<String, List<Tuple2<CatalogTable, Action>>> tuple2 =
                        parseSource(configIndex, sourceConfig, sourceAndTransformClassLoader);
                tableWithActionMap.put(tuple2._1(), tuple2._2());
            }
            boolean hasSourceTables =
                    tableWithActionMap.values().stream().anyMatch(actions -> !actions.isEmpty());
            if (!sourceConfigs.isEmpty()
                    && !hasSourceTables
                    && MultiTableFailureHelper.shouldContinueOtherTables(envOptions)) {
                throw new JobDefineCheckException(
                        "No source tables were available after discovery. "
                                + "Check source-side failed-table warnings for details.");
            }

            log.info("start generating all transforms.");
            parseTransforms(transformConfigs, sourceAndTransformClassLoader, tableWithActionMap);

            Thread.currentThread().setContextClassLoader(sinkClassLoader);
            log.info("start generating all sinks.");
            List<Action> sinkActions = new ArrayList<>();
            for (int configIndex = 0; configIndex < sinkConfigs.size(); configIndex++) {
                Config sinkConfig = sinkConfigs.get(configIndex);
                sinkActions.addAll(
                        parseSink(configIndex, sinkConfig, sinkClassLoader, tableWithActionMap));
            }
            if (sinkActions.isEmpty() && !failedTables.isEmpty()) {
                throw new JobDefineCheckException(
                        buildFailureSummary(

View on GitHub (pinned to cf67b549a7)

Solutions

1. Scan earlier WARN logs for per-table failed-table messages (MultiTableFailureHelper) to find the root cause per table.
2. Fix catalog connection settings (url, user, password, database) in each source config.
3. Verify referenced tables/databases exist and are accessible with the configured credentials.
4. Confirm the connector plugin jar is installed in connectors/; add it via install-plugin.sh if missing.
5. If fail-fast behavior is preferred instead of tolerating skipped tables, disable the continue-on-failed-tables option so the first real error surfaces.

Example fix

// before
source {
  MySQL {
    url = "jdbc:mysql://localhost:3306/wrong_db"
    table_names = ["inventory.orders"]
  }
}
// after
source {
  MySQL {
    url = "jdbc:mysql://localhost:3306/inventory"
    table_names = ["inventory.orders"]
    user = "app"
    password = "******"
  }
}

// before submitting, verify each source table is reachable
for (String table : sourceTables) {
  boolean ok = catalog.tableExists(table); // also check credentials/connectivity
  if (!ok) throw new IllegalStateException("Source table not discoverable: " + table);
}

try {
  engine.submitJob(config);
} catch (JobDefineCheckException e) {
  if (e.getMessage().contains("No source tables were available after discovery")) {
    // inspect failed-table warnings, fix source catalog configs, then resubmit
  }
}

When it happens

Trigger: Calling job parsing (JobConfigParser.parse / immutablePair path) when: sourceConfigs is non-empty, tableWithActionMap has no non-empty action lists, and envOptions enable shouldContinueOtherTables (skip-failed-tables tolerance mode).

Common situations: All source tables point to nonexistent databases/tables, wrong catalog credentials for every source, network/firewall blocking the source DB, or incompatible connector plugin missing so each table fails during discovery in tolerant mode.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors

• All candidate sink tables were skipped during job parsing.
• Duplicated transform name '%s'. Transform names must be uniq
• The SQL config must contain at least one source table
• The SQL config must contain `INSERT INTO ... SELECT ...` syn
• Table name duplicate: %s

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/f518646a1e0a729a. Report an issue: GitHub.