Failed to evaluate recovered split

Error message

Failed to evaluate recovered split {}, re-enqueue it conservatively.

What it means

When recovering splits from a checkpoint, the enumerator calls context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode) to decide whether a recovered split still needs processing. If that evaluation throws an IOException (e.g. probing file status fails), it logs this warning and conservatively sets shouldProcess = true, so the split is re-enqueued and reprocessed rather than skipped. This favors reprocessing over data loss.

Solutions

Fix the underlying filesystem error shown in the logged exception
Expect possible duplicate reprocessing of the affected splits; ensure downstream can tolerate or deduplicate re-reads
Verify source paths referenced by the checkpoint still exist before restarting the job

Defensive patterns

Strategy: retry

Validate before calling

// Before restoring, confirm all checkpointed split source files still exist
for (FileSourceSplit s : recoveredSplits) {
    if (!fs.exists(s.getFilePath())) {
        log.warn("Recovered split source missing: {}", s.getFilePath());
    }
}

Try / catch

try {
    shouldProcess = context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode);
} catch (IOException e) {
    log.warn("Failed to evaluate recovered split {}, re-enqueue it conservatively.",
            maskUriUserInfo(split.getFilePath()), e);
    shouldProcess = true;
}

Prevention

Verify source files referenced by checkpoints still exist before restarting
Restore only on a healthy filesystem connection
Design downstream sinks to deduplicate re-read data, since conservative re-enqueue may reprocess files

When it happens

Trigger: recoverSplitsFromCheckpoint processing a split whose source file status cannot be evaluated — the file or its directory is temporarily inaccessible, or the filesystem throws while checking status/paths needed by shouldProcess.

Common situations: Restart from checkpoint while the source filesystem is degraded; files deleted between checkpoint and recovery; transient FS errors at job recovery time.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

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

Appendix: source

Thrown at seatunnel-connectors-v2/connector-file/connector-file-base/src/main/java/org/apache/seatunnel/connectors/seatunnel/file/source/split/ContinuousMultipleTableFileSourceSplitEnumerator.java:542

            FileStatus sourceStatus;
            try {
                sourceStatus = context.sourceFs.getFileStatus(split.getFilePath());
            } catch (IOException e) {
                if (log.isDebugEnabled()) {
                    log.debug(
                            "Skip recovering split because source file status cannot be resolved: {}",
                            maskUriUserInfo(split.getFilePath()),
                            e);
                }
                skipped++;
                continue;
            }

            boolean shouldProcess;
            try {
                shouldProcess = context.shouldProcess(sourceStatus, jobStartTimeMillis, startMode);
            } catch (IOException e) {
                log.warn(
                        "Failed to evaluate recovered split {}, re-enqueue it conservatively.",
                        maskUriUserInfo(split.getFilePath()),
                        e);
                shouldProcess = true;
            }
            if (!shouldProcess) {
                skipped++;
                continue;
            }

            synchronized (lock) {
                pendingSplits.addLast(split);
                pendingSplitIds.add(split.splitId());
                SplitVersion splitVersion = SplitVersion.fromFileStatus(sourceStatus);
                pendingSplitVersions.put(split.splitId(), splitVersion);
                knownSplitVersions.put(split.splitId(), splitVersion);
            }
            recovered++;

View on GitHub (pinned to cf67b549a7)