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.