Repository navigation
RST_STREAM error keeps showing up #7490
Description
Environment details
- OS: macOS Catalina 10.15.5 Beta (19F53f)
- Node.js version: 13.7.0
- npm version: 6.13.6
@google-cloud/firestoreversion: 3.7.4
Steps to reproduce
This error keeps appearing over and over in my logs (not regularly reproducible):
Error: 13 INTERNAL: Received RST_STREAM with code 2
at Object.callErrorFromStatus (/api/node_modules/@grpc/grpc-js/src/call.ts:81)
at Object.onReceiveStatus (/api/node_modules/@grpc/grpc-js/src/client.ts:324)
at Object.onReceiveStatus (/api/node_modules/@grpc/grpc-js/src/client-interceptors.ts:439)
at Object.onReceiveStatus (/api/node_modules/@grpc/grpc-js/src/client-interceptors.ts:402)
at Http2CallStream.outputStatus (/api/node_modules/@grpc/grpc-js/src/call-stream.ts:228)
at Http2CallStream.maybeOutputStatus (/api/node_modules/@grpc/grpc-js/src/call-stream.ts:278)
at Http2CallStream.endCall (/api/node_modules/@grpc/grpc-js/src/call-stream.ts:262)
at ClientHttp2Stream.<anonymous> (/api/node_modules/@grpc/grpc-js/src/call-stream.ts:532)
at ClientHttp2Stream.emit (events.js:315)
at ClientHttp2Stream.EventEmitter.emit (domain.js:485)
at emitErrorCloseNT (internal/streams/destroy.js:76)
at processTicksAndRejections (internal/process/task_queues.js:84)
Reacted by Sebastian Kreft, Natan Sągol, Nish Sowdri, Lars Rye Jeppesen, Pavel Puchkov, Adriano Cardoso, Nate Foss, Will Yu, Joshua McFarland, giiiita and 78 more
Activity
[-]Bandwidth exhausted consistently showing up[/-][+]RST_STREAM error keeps showing up[/+]schmidt-sebastian commentedon Apr 17, 2020
@jakeleventhal Thanks for filing this. Do you know at all what type of request/API call this is related to?
jakeleventhal commentedon Apr 19, 2020
The only place i use grpc is via firestore so it must be something from there. I don't really have more info unfortunately
whyvrafvr commentedon May 15, 2020
I also got this one with
firebase-admin8.12.1 :whyvrafvr commentedon May 15, 2020
This is a weird jeopardize issue, thrown during
deleteascreateor whatever request type...schmidt-sebastian commentedon May 18, 2020
All document modifications (e.g.
delete(),create()) use the same underlying request type. This request type is not safe for automatic retry, so unfortunately we cannot simply retry these errors.whyvrafvr commentedon May 20, 2020
Hi @schmidt-sebastian.
I do confirm the request type is not safe.
Retrying many times the same call (and so, the same request, I guess) has no significant effect.
But there is no error when the
nodejsinstance is restarted : I guess a GRPC subroutine is hanging out.whyvrafvr commentedon May 20, 2020
After a while, errors, as mentioned by @jakeleventhal, are thrown and it’s not possible to persist data in firestore and an instance restart is required. That’s a real problem folks 😄
FYI, I’ve no issue using firestore delete(), create() methods with Go...
160 remaining items
Jhon-Idrovo commentedon Jul 5, 2024
FIXED: While I was looking at the files I noticed the env variable NODE_ENV was unset. So I was trying to reach the emulator instead of the production DB. So if you're having this issue, check what you're connecting to
leeyongeun9 commentedon Nov 28, 2024
Is there any update or progress regarding this issue? In my case, I encounter this problem frequently (~ 30 times per day) across various parts of my project where the
reference.update()function is called. These errors pose a significant risk to my service, as they can lead to data inconsistencies.Below are logs from a single day, each occurring at different points in the code:
BrodaNoel commentedon Nov 28, 2024
I never got this issue again. Are you sure you are in the latest version of all the dependencies?
leeyongeun9 commentedon Nov 30, 2024
Yes I updated all the dependencies and deplyed the functions after I wrote the reply but the errors still occured
Environment Details
snallapa commentedon Dec 19, 2024
running into this as well when doing a rather heavy migration
AndersonFerreiraSantos commentedon May 5, 2025
I have the same problem, apparently we don't have any solution at the moment, right? In my case, it seems that this problem occurs when my client has a very long duration.
AndersonFerreiraSantos commentedon May 8, 2025
Hi, I have a data import tool, the instances are used for long periods of time and I ended up getting this error.
My solution was to add a time limit for the new Datastore, in this case I set it to 1 minute, but that's due to the large number of operations I perform, I tested with smaller modules and was successful with 30 minutes.
Here's an example:
` const CLIENT_TTL = 1 * 60 * 1000;
const datastoreClients = new TTLCache({ ttl: CLIENT_TTL });
const getDatastoreClient = (_projectId = undefined) => {
const projectId = getProjectId(_projectId);
if (!datastoreClients.has(projectId)) {
datastoreClients.set(projectId, new Datastore(Object.assign(Object.assign({}, datastoreConfig), { projectId: projectId })));
}
return datastoreClients.get(projectId);
};`
Akash16s commentedon Jun 29, 2025
I’ve run into this exact problem when hammering Firestore with very high write volumes (over 10 000 writes/sec per collection).
To help, I built firestore-retry (https://www.npmjs.com/package/firestore-retry), which wraps your write calls in exponential backoff and retry logic.
It won’t remove Firestore’s rate limits, but it will smooth out bursts and give you some breathing room while you scale. Let me know how it works for you!
danbaechtold commentedon Dec 16, 2025
Gemini 3 Pro seems to know where the bug comes from:
It suggested to me to restart the listeners every 50min or so.. but is that really required and a smart thing to do?