Failed to close the source reader in {} ms. There are still

Error message

Failed to close the source reader in {} ms. There are still {} split fetchers running

What it means

SplitFetcherManager.close shuts down all split fetchers and awaits executor termination within timeoutMs. If fetchers do not finish in time, this warning reports how many fetchers are still running. Data may still be in flight and the source reader was not cleanly closed — often a symptom of a fetcher blocked on a slow network read or a task that ignores interrupts.

Source

Thrown at seatunnel-connectors-v2/connector-common/src/main/java/org/apache/seatunnel/connectors/seatunnel/common/source/reader/fetcher/SplitFetcherManager.java:136

        Iterator<Map.Entry<Integer, SplitFetcher<E, SplitT>>> iter = fetchers.entrySet().iterator();
        while (iter.hasNext()) {
            Map.Entry<Integer, SplitFetcher<E, SplitT>> entry = iter.next();
            SplitFetcher<E, SplitT> fetcher = entry.getValue();
            if (fetcher.isIdle()) {
                log.info("Closing splitFetcher {} because it is idle.", entry.getKey());
                fetcher.shutdown();
                iter.remove();
            }
        }
        return fetchers.isEmpty();
    }

    public synchronized void close(long timeoutMs) throws Exception {
        closed = true;
        fetchers.values().forEach(SplitFetcher::shutdown);
        executors.shutdown();
        if (!executors.awaitTermination(timeoutMs, TimeUnit.MILLISECONDS)) {
            log.warn(
                    "Failed to close the source reader in {} ms. There are still {} split fetchers running",
                    timeoutMs,
                    fetchers.size());
        }
    }

    public void checkErrors() {
        if (uncaughtFetcherException.get() != null) {
            throw new RuntimeException(
                    "One or more fetchers have encountered exception",
                    uncaughtFetcherException.get());
        }
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

Increase the close timeout passed to close(timeoutMs) so slow fetchers can finish
Investigate why fetchers hang: check network connectivity/latency to the source and source-side consumer lag
Check that the SplitFetcher loop reacts promptly to shutdown (bounded blocking calls, interruptible I/O); fix the reader/fetcher implementation if it blocks indefinitely

Example fix

// before
splitFetcherManager.close(1000);
// after
splitFetcherManager.close(60000); // give fetchers time to drain

Defensive patterns

Strategy: try-catch

Validate before calling

// Ensure fetchers are idle before closing
if (!splitFetcherManager.isIdle()) { drainOrCancelSplitsFirst(); }

Try / catch

try {
  splitFetcherManager.close(timeoutMs);
} catch (Exception e) {
  log.warn("Source reader close incomplete; fetchers may still be running", e);
  // optionally: force shutdown or escalate
}

Prevention

Use generous close timeouts relative to worst-case fetch latency
Monitor source network health; hung fetchers usually mean hung connections
Ensure custom readers use interruptible/bounded blocking I/O

When it happens

Trigger: Calling sourceReader.close(timeoutMs) (e.g. during job cancellation/checkpoint) while fetchers are blocked in long network I/O against the upstream source (Kafka, file reads, etc.) exceeding the timeout.

Common situations: Slow or hung upstream source connection; timeoutMs configured too small; fetcher stuck in a blocking poll that ignores shutdown signal; network partition during job teardown.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

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