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

Error message

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

What it means

In AbstractSplitEnumerator.addSplitsBack, splits returned by a failed reader are re-queued as pending, but if that subtask's reader is not yet registered with the SourceReaderContext, the enumerator cannot assign to it and logs this warning. The splits remain pending and will be assigned once the reader registers (or on the next assignment round). It is a race-condition guard for failover/restart, not a fatal error.

Source

Thrown at seatunnel-connectors-v2/connector-iceberg/src/main/java/org/apache/seatunnel/connectors/seatunnel/iceberg/source/enumerator/AbstractSplitEnumerator.java:140

                                                            context.currentParallelism()),
                                                    r -> new ArrayList<>())
                                            .add(split));
        }
    }

    @Override
    public void open() {
        log.info("Open split enumerator.");
    }

    @Override
    public void addSplitsBack(List<IcebergFileScanTaskSplit> splits, int subtaskId) {
        if (!splits.isEmpty()) {
            addPendingSplits(splits);
            if (context.registeredReaders().contains(subtaskId)) {
                assignPendingSplits(Collections.singleton(subtaskId));
            } else {
                log.warn(
                        "Reader {} is not registered. Pending splits {} are not assigned.",
                        subtaskId,
                        splits);
            }
        }
        log.info("Add back splits {} to JdbcSourceSplitEnumerator.", splits.size());
    }

    @Override
    public int currentUnassignedSplitSize() {
        if (!pendingTables.isEmpty()) {
            return pendingTables.size();
        }
        if (!pendingSplits.isEmpty()) {
            return pendingSplits.values().stream().mapToInt(List::size).sum();
        }
        return 0;
    }

View on GitHub (pinned to cf67b549a7)

Solutions

No action usually needed — splits are kept pending and assigned after the reader registers
Check that the source's reader registration/lifecycle is intact (start() called, context registration reaches coordinator)
If splits stay unassigned, restart the job and verify reader registration in logs
Ensure SourceReaderContext sends RegisterReader event before first split request in custom source code

Defensive patterns

Strategy: fallback

Prevention

Accept the pending-splits fallback as normal failover behavior
Monitor logs to confirm readers re-register and pending splits are drained
Keep cluster resources stable to minimize reader failovers
Verify checkpoint restore completes before stressing the source

When it happens

Trigger: Reader failover or job restore: addSplitsBack(subtaskId) is called for a reader that hasn't (re)registered with the SourceSplitCoordinator yet (registeredReaders() doesn't contain subtaskId).

Common situations: Worker node failure during Iceberg source execution; checkpoint restore where the enumerator recovers splits before the new reader registers; slow reader startup after rescale.

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/374aac2e165ab112. Report an issue: GitHub.