Add native AbortSignal support to Firestore Node.js client APIs

[natilivni]

Feature Request: Add native AbortSignal support to Firestore Node.js client APIs

I’d like to request native AbortSignal support in the Node.js Firestore client (@google-cloud/firestore), so that operations like .get(), .runQuery(), .listDocuments(), etc., can be cancelled mid-flight.

Motivation & Use Cases

• Many Firestore operations can run for a significant amount of time (large queries, multi-document reads, long-running streaming operations).
• In modern JavaScript and Node.js, AbortController / AbortSignal has become the standard cancellation API — supported in built-in fetch(), many web APIs, and Node.js core libraries since v15.
• In server contexts (e.g., Cloud Functions, HTTP services), it’s often necessary to cancel pending work when the client disconnects or a request times out, to free up resources.

Technical Feasibility

• Under the hood, @google-cloud/firestore calls into google-gax and the generated v1.FirestoreClient.
• google-gax already returns CancellablePromise for unary RPCs and CancellableStream for streaming RPCs, both of which expose .cancel() to abort the gRPC call and tear down the socket.
• Surfacing this at the high-level Firestore API could be done by:
  1. Accepting an optional signal?: AbortSignal parameter in public methods.
  2. Wiring signal.addEventListener('abort', ...) to call the underlying .cancel() method.

Example

const controller = new AbortController();

const snapshotPromise = firestore.collection('users').get({ signal: controller.signal });

// Cancel after 1 second
setTimeout(() => controller.abort(new Error('Timeout')), 1000);

await snapshotPromise; // Would reject immediately if aborted

Benefits

• Aligns Firestore client with modern JavaScript ecosystem standards.
• Allows real network-level cancellation instead of “soft” Promise.race cancellation.
• Reduces wasted CPU/memory by aborting in-flight work when no longer needed.

Thanks for considering this request! I’m happy to develop it in a fork myself, help test or provide feedback.

[MarkDuckworth]

@natilivni. Thanks for the feature request. I'm bringing this to the team for consideration.

[MarkDuckworth]

@natilivni, can you tell me more about your goals. Is this cancellation meant to achieve savings on Firestore read costs? Or is this simply a step to clean up network requests from your app? How often does your app experience a query that would need to be cancelled?

[MarkDuckworth]

Googler's see internal tracking (b/439877462) for relevant conversations.

[natilivni]

Hi @MarkDuckworth! We want to achieve two main goals:

1. To centralize our timeouts. For example, if we do a set of actions under a message handler that has a certain period of time allowed for processing. When that time ends, we want to clean up any remaining calls which would, under the current api, continue in the background.
2. Clean shutdown of our process. When we send a kill command to our process, we have a certain period of time in which to finish remaining work. We would like the ability to explicitly cancel firestore threads before we do some other cleanup.

We sometimes also experience delays due to contention or due to network instability and when this happens, we would like a way to cancel calls that are taking a long time.

The frequency of this need depends on the load on our system. But it happens several times every day.

[natilivni]

Hi @MarkDuckworth, any update on this? If you want I would be happy to create a fork and offer an implementation for you to approve.

[natilivni]

Hi @MarkDuckworth, would it be possible for me to contribute this issue? If so, what is the procedure?

[natilivni]

Hi @MarkDuckworth, I created a proposed PR for this implementation for your consideration:

googleapis/nodejs-firestore#2440

[natilivni]

Hi @MarkDuckworth, I know it's not high priority but is there an ETA of when you can take a look at the PR?

[natilivni]

Hi @MarkDuckworth, any update on when this will be considered?