What causes "Close Firestore client failed." in apache/seatunnel?

Inspect the wrapped cause (the exception carries the original 'e') to identify the underlying transport problem.

apache/seatunnel · warning · FirestoreConnectorException

CLOSE_CLIENT_FAILED

CLOSE_CLIENT_FAILED

Error message

Close Firestore client failed.

What it means

FirestoreSinkWriter.close() wraps the Firestore client's own close() call; if firestore.close() throws for any reason, the writer rethrows it as a FirestoreConnectorException with code CLOSE_CLIENT_FAILED. This signals that gRPC channels/resources backing the Firestore client could not be shut down cleanly.

Source

Thrown at seatunnel-connectors-v2/connector-google-firestore/src/main/java/org/apache/seatunnel/connectors/seatunnel/google/firestore/sink/FirestoreSinkWriter.java:79

                        .setCredentials(credentials)
                        .build();
        this.firestore = firestoreOptions.getService();
        this.collectionReference = firestore.collection(parameters.getCollection());
        this.serializer = new DefaultSeaTunnelRowSerializer(seaTunnelRowType);
    }

    @Override
    public void write(SeaTunnelRow seaTunnelRow) throws IOException {
        collectionReference.add(serializer.serialize(seaTunnelRow));
    }

    @Override
    public void close() throws IOException {
        if (firestore != null) {
            try {
                firestore.close();
            } catch (Exception e) {
                throw new FirestoreConnectorException(
                        FirestoreConnectorErrorCode.CLOSE_CLIENT_FAILED,
                        "Close Firestore client failed.",
                        e);
            }
        }
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

Inspect the wrapped cause (the exception carries the original 'e') to identify the underlying transport problem.
Ensure the network to Firestore is stable at job teardown; retry the job if it was a transient shutdown race.
If it recurs on cancellation, upgrade the connector / gRPC version where shutdown races are fixed; it is usually harmless since the process is exiting anyway.

Defensive patterns

Strategy: try-catch

Try / catch

try {
  writer.close();
} catch (FirestoreConnectorException e) {
  log.warn("Firestore client close failed (cause: {}). Resources will be reclaimed by JVM exit.", e.getCause(), e);
  // do not fail the whole job for a shutdown-time close error
}

Prevention

Ensure stable network connectivity to Firestore during job teardown.
Avoid hard-cancelling jobs with large in-flight write batches.
Check the wrapped cause; repeated failures may indicate a gRPC version issue worth upgrading.

When it happens

Trigger: Writer close() is invoked (task shutdown, job finish, failover) while firestore != null and the underlying Firestore client's close() throws — e.g. interrupted gRPC shutdown, already-aborted transport.

Common situations: Job cancellation with in-flight RPCs; network partitions at shutdown time; JVM shutdown hooks competing with the writer's close.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

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