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

Error message

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

What it means

InfluxDBSourceSplitEnumerator.addSplitsBack re-queues splits returned by a failed/recovered reader; if the subtask's reader is not registered with the coordinator yet, the splits cannot be assigned and this warning is logged. Splits stay pending and are assigned after the reader registers. This is an expected race during failover, not a data-loss condition.

Source

Thrown at seatunnel-connectors-v2/connector-influxdb/src/main/java/org/apache/seatunnel/connectors/seatunnel/influxdb/source/InfluxDBSourceSplitEnumerator.java:100

            }

            assignSplit(readers);
        }

        log.debug(
                "No more splits to assign." + " Sending NoMoreSplitsEvent to reader {}.", readers);
        readers.forEach(context::signalNoMoreSplits);
    }

    @Override
    public void addSplitsBack(List<InfluxDBSourceSplit> splits, int subtaskId) {
        log.debug("Add back splits {} to InfluxDBSourceSplitEnumerator.", 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.size();
    }

    @Override
    public void registerReader(int subtaskId) {
        log.debug("Register reader {} to InfluxDBSourceSplitEnumerator.", subtaskId);
        if (!pendingSplit.isEmpty()) {
            assignSplit(Collections.singletonList(subtaskId));
        }

View on GitHub (pinned to cf67b549a7)

Solutions

Usually no action needed — pending splits are assigned once the reader registers
If splits never get assigned, check reader registration flow and restart the job
Ensure stable cluster resources to reduce reader failover frequency
Verify SourceReaderContext registration events are not dropped in custom coordinator code

Defensive patterns

Strategy: fallback

Prevention

Treat the warning as normal during failover; ensure pending splits drain afterward
Monitor reader registration events after restarts
Keep TaskManager/worker failures low via adequate resources
Test job restore flows to confirm splits are reassigned

When it happens

Trigger: addSplitsBack(splits, subtaskId) invoked (e.g. by the SourceCoordinator on reader failure/restore) while context.registeredReaders() does not contain subtaskId — reader hasn't re-registered after restart/failover.

Common situations: TaskManager loss during InfluxDB read; checkpoint restore starting the enumerator before readers reconnect; rescaling that moves readers between workers.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

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