Firestore update method throw error: "Error: 13 INTERNAL: Received RST_STREAM with code 1"
Asked Answered
T

1

11

While using Cloud Functions, we've encountered the following error:

Timestamp: 2023-10-21 18:50:18.281 EEST Function: v8-specialist

---updateUserByID finish update---

Caused by: Error 
    at WriteBatch.commit (/workspace/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/write-batch.js:433:23) 
    at DocumentReference.update (/workspace/node_modules/firebase-admin/node_modules/@google-cloud/firestore/build/src/reference.js:433:14) 
    at Object.updateUserByID (/workspace/dist/src/DB/db.js:74:14) 
    at createSpecialistOrderListService (/workspace/dist/src/crud/specialist/services/specialistList/createSpecialistOrderListService.js:38:29) 
    at runMicrotasks (<anonymous>) 
    at processTicksAndRejections (node:internal/process/task_queues:96:5) 
    at async getRecommendedSpecialistsListController (/workspace/dist/src/crud/specialist/controllers/getRecommendedSpecialistsListController.js:25:44) 
    at async /workspace/dist/src/framework/express/middlewares/express-handler.js:18:36 

Error Details:
- Code: `13`
- Description: `Received RST_STREAM with code 1`
- Metadata: `{ internalRepr: Map(0) {}, options: {} }`
- Note: `Exception occurred in retry method that was not classified as transient`

This error seems to pop up when we execute the following command in our update function:

const writeResult = await admin
      .firestore()
      .collection(FirestoreCollections.Users)
      .doc(userID)
      .update(fieldsToUpdate);

Example of fieldsToUpdate:

[
  {
    "boolean": true,
    "number": 100,
    "id": "some_id"
  }
]

However, what's puzzling is that this method seems to work flawlessly in our other cloud functions. In certain situations, even if an error is thrown during the update, the data in Firestore might still get updated.

  1. The issue persists even when tested locally.
  2. Upon creating a new cloud function with the same method, everything operates smoothly.
Traveller answered 21/10, 2023 at 17:23 Comment(3)
Some updates: in our develop project everything works fine(The only difference is that the development project has a smaller User collection, in production number of documents more than 200k), switched the update method to use set and set with {merge: true}, but this didn't work, create new cloud function with only update firestore logic didnt work too in production env. the error occurred in production 15,000 times in the last 3 days 60% of update requests fail with this error...Traveller
I'm experiencing the exact same thing.Tantrum
I have a function that runs in production every hour. The first time the error occurred: timestamp: "2023-10-09T19:01:30.561443Z". The error only happens with scheduled functions functions .region('europe-west1').pubsub.schedule('every 1 hours').(...)Ladanum
W
5

I had the same problem last week and it seems to be something inside firebase / grpc implementation related to long time delays between firebase calls.

Also, firebase library seems to be moving away from RPC but it still keeps it as a default option if you don't set preferRest: true (see docs)

For me it works when I call init right before performing an operation or changing firebase config to prefer using rest comunication.

Here is my code snipet:

function getFbDb() {
  const mainFirebaseApp = firebaseAdmin.initializeApp({
      credential: firebaseAdmin.credential.applicationDefault()
    }, uuid.v4());

  const db = mainFirebaseApp.firestore();
  const settings = {
    preferRest: true,
    timestampsInSnapshots: true
  };
  db.settings(settings);
  return { db, firebaseApp: mainFirebaseApp };
}
const { db, firebaseApp } = getFbDb();

Use const { db, firebaseApp } = getFbDb(); everytime you have to execute an operation.

Another "dirty option" seems to be using a retry approach after the first fail.

If this doesn't work for you keep an eye on issue 2345 and see what comes up from there.

Wangle answered 23/10, 2023 at 21:56 Comment(2)
Hi! Thank you for taking the time to help out. As I pointed out in my github comment: github.com/firebase/firebase-admin-node/issues/…, we've optimized our algorithms between interacts with Firebase, and bug fixed. We haven't experimented with preferRest: true yet, but it does look promising. I'll keep it in mind for future reference. I'll mark this as solved. Thanks again!Traveller
Setting preferRest: true worked for me. => const fbApp = admin.initializeApp(); const db = fbApp.firestore(); db.settings({preferRest: true});Ladanum

© 2022 - 2024 — McMap. All rights reserved.