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

Error message

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

What it means

DorisSourceSplitEnumerator.addSplitsBack receives splits returned by a failed/restarted reader and tries to reassign them. If the subtask's reader is not currently registered with the SourceCoordinator/SplitEnumeratorContext, the splits stay pending and this warning is emitted — the data will only be assigned once that reader registers again.

Source

Thrown at seatunnel-connectors-v2/connector-doris/src/main/java/org/apache/seatunnel/connectors/doris/source/split/DorisSourceSplitEnumerator.java:114

                shouldEnumerate = false;
                assignSplit(readers);
            }
        }

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

    @Override
    public void addSplitsBack(List<DorisSourceSplit> splits, int subtaskId) {
        log.debug("Add back splits {} to DorisSourceSplitEnumerator.", splits);
        if (!splits.isEmpty()) {
            addPendingSplit(splits);
            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 this.pendingSplit.size();
    }

    @Override
    public void handleSplitRequest(int subtaskId) {
        throw new DorisConnectorException(
                CommonErrorCodeDeprecated.UNSUPPORTED_OPERATION,
                String.format("Unsupported handleSplitRequest: %d", subtaskId));
    }

View on GitHub (pinned to cf67b549a7)

Solutions

No user action is usually needed: splits are kept pending and reassigned when the reader re-registers.
Check worker logs for the reader's registration failure if the warning persists — often a worker crash loop.
Ensure cluster resources are sufficient so failed workers restart successfully.
If a subtask id never appears again (e.g. parallelism was reduced), restart the job from a consistent checkpoint.

Defensive patterns

Strategy: fallback

Try / catch

// No caller action required: splits remain pending and are assigned when the reader registers; only investigate if the warning repeats without eventual assignment.

Prevention

Ensure workers restart promptly after failure so readers re-register
Avoid reducing parallelism while restoring from checkpoints of higher parallelism
Monitor job logs for repeated reader-registration warnings as a crash-loop signal

When it happens

Trigger: Calling addSplitsBack(splits, subtaskId) during failure recovery when context.registeredReaders() does not contain subtaskId — i.e., the reader failed before (re)registering while its splits were being returned.

Common situations: TaskManager/worker crash and quick restart racing with split return; Flink/Zeta job failover where a new reader has not yet registered; excessive parallelism changes leaving stale subtask ids; checkpoint restore assigning splits to a reader that never came back.

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