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

Error message

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

What it means

A WARN logged by EasysearchSourceSplitEnumerator.addSplitsBack when failed splits are returned for a subtaskId whose reader is not currently registered with the split enumerator context. The splits are stored as pending and will only be assigned once the reader re-registers; until then they sit unassigned.

Source

Thrown at seatunnel-connectors-v2/connector-easysearch/src/main/java/org/apache/seatunnel/connectors/seatunnel/easysearch/source/EasysearchSourceSplitEnumerator.java:189

                                    scrollTime,
                                    scrollSize)));
        }
        return splits;
    }

    @Override
    public void close() throws IOException {
        ezsClient.close();
    }

    @Override
    public void addSplitsBack(List<EasysearchSourceSplit> splits, int subtaskId) {
        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) {
        throw new EasysearchConnectorException(
                UNSUPPORTED_OPERATION, "Unsupported handleSplitRequest: " + subtaskId);
    }

View on GitHub (pinned to cf67b549a7)

Solutions

Confirm the reader eventually restarts and re-registers — pending splits are then assigned automatically.
Check the reader's failure logs for the root cause of the un-registration.
If splits stay pending indefinitely, restart the job from the last checkpoint.
Ensure the engine's recovery settings (restarting strategy) are enabled so readers re-register after failure.

Defensive patterns

Strategy: validation

Validate before calling

if (!context.registeredReaders().contains(subtaskId)) {
    log.warn("reader {} not registered; splits kept pending", subtaskId);
}

Prevention

Enable a restarting strategy so failed readers re-register
Investigate reader failure root causes promptly
Restart from checkpoint if pending splits never drain

When it happens

Trigger: Calling addSplitsBack (e.g. on reader failure/rollback) with a subtaskId not present in context.registeredReaders() — typically when the reader already failed permanently or the failure notification races with split return.

Common situations: Reader task crashed and was not yet restarted/re-registered when its splits came back; engine checkpoint recovery races; duplicated addSplitsBack calls after a reader failure.

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