Reader {} is not registered. Pending splits {} are not assig

Error message

Reader {} is not registered. Pending splits {} are not assigned.

What it means

When the TiDB CDC split enumerator receives splits back from a failed/restarted reader via addSplitsBack, it queues them as pending for that subtask. If the subtask is not in context.registeredReaders() (reader crashed and has not re-registered yet), the pending splits are held but not assigned, and this warning is logged. Assignment will happen when the reader re-registers.

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-tidb/src/main/java/org/apache/seatunnel/connectors/seatunnel/cdc/tidb/source/enumerator/TiDBSourceSplitEnumerator.java:208

        }
    }

    /**
     * Add a split back to the split enumerator. It will only happen when a {@link SourceReader}
     * fails and there are splits assigned to it after the last successful checkpoint.
     *
     * @param splits The split to add back to the enumerator for reassignment.
     * @param subtaskId The id of the subtask to which the returned splits belong.
     */
    @Override
    public void addSplitsBack(List<TiDBSourceSplit> splits, int subtaskId) {
        log.debug("Add back splits {} to TiDBSourceSplitEnumerator.", splits);
        if (!splits.isEmpty()) {
            addPendingSplit(splits, subtaskId);
            if (context.registeredReaders().contains(subtaskId)) {
                assignSplit(Collections.singletonList(subtaskId));
            } else {
                log.warn(
                        "Reader {} is not registered. Pending splits {} are not assigned.",
                        subtaskId,
                        splits);
            }
        }
    }

    @Override
    public int currentUnassignedSplitSize() {
        return pendingSplit.values().stream().mapToInt(List::size).sum();
    }

    @Override
    public void handleSplitRequest(int subtaskId) {}

    @Override
    public void registerReader(int subtaskId) {
        log.debug("Register reader {} to TiDBSourceSplitEnumerator.", subtaskId);

View on GitHub (pinned to cf67b549a7)

Solutions

No action usually needed: splits stay pending and are reassigned when the reader re-registers (registerReader triggers assignment).
If splits stay unassigned, restart the job from the last checkpoint so reader registration and split state are consistent.
Check reader failure logs for the root cause of the reader loss (network, OOM).

Defensive patterns

Strategy: retry

Prevention

Rely on re-registration: pending splits are reassigned automatically when the reader reconnects
Monitor job metrics for stuck pending-split counts
Keep checkpointing enabled so failover restores consistent enumerator/reader state

When it happens

Trigger: Reader failure/restore causing SourceReader to send back splits (addSplitsBack) while its subtaskId is no longer in the enumerator's registered reader set.

Common situations: Worker crash or checkpoint restore racing with split return; reader failing health checks and being deregistered before addSplitsBack arrives.

Related errors

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