Sudden spike in Firestore reads in Next.js app after no changes - please see graph

Question

In the graph days 1-10 I was working on the project - The reads you can see range between 100 - 300 per day, regularly refreshing a list of documents from firestore. Days 11-15 I was visiting family and away from the project. On day 16, I launched the project for fifteen minutes but didn't make any changes (I didn't notice it spike so high because it wasn't over quota and I wasn't developing or keeping track). And today whilst actually working on the project I hit my free quota. The spike happened within two hours of me starting work.

I think the reads are coming from this clientList component in my Next.js app:

let unsubscribe;
const Clients = () => {
  const classes = useStyles();
  firebase.auth().onAuthStateChanged(function (user) {
    if (user) {
      const db = firebase.firestore();
      unsubscribe = db.collection("users")
        .doc(user.uid)
        .collection("clients")
        .onSnapshot((snap) => {
          const clients = snap.docs.map((doc) => ({
            id: doc.id,
            ...doc.data(),
          }));
          unsubscribe();
          setClients(clients);
        });
    } else {
      [];
    }
  });

 

  const [clients, setClients] = useState([]);

  return (


    <Fragment>
      {clients.map((client, i) => (
        <Paper className={classes.paper} key={client.id}>
          <Typography
            className={client.name}
            color="textSecondary"
            gutterBottom
          >
            {client.name}
          </Typography>
  
        </Paper>
      ))}
    </Fragment>

  );
};

export default Clients;

In panic I changed my security details from:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth.uid != null;
    }
    match /users/{userId}/clients/{document=**} {
      allow read: if request.auth.uid == userId;
    }
  }
}

back to this:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // This rule allows anyone with your database reference to view, edit,
    // and delete all data in your Firestore database. It is useful for getting
    // started, but it is configured to expire after 30 days because it
    // leaves your app open to attackers. At that time, all client
    // requests to your Firestore database will be denied.
    //
    // Make sure to write security rules for your app before that time, or else
    // all client requests to your Firestore database will be denied until you Update
    // your rules
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2019, 9, 10);
    }
  }
}

Until i'm sure my original security rules were okay. My last commit to clientList.js was on day 10. Today whilst working on the project I was working on showing and hiding a form using a button, both of which have nothing to do with clientList.js (referred to as Client due to dynamic import) or Firestore.

I don't currently use the firebase CLI, and would have had one firestore dashboard chrome window open and one localhost window open (the same as the ten days not over or near quota). There were no unrecognised auth'd users and anonymous auth isn't an option.

Can anyone advise me on how to troubleshoot something like this?

score 1 · Answer 1 · answered Sep 17 '20 at 14:32

You can check stackdriver in GCP cloud console for any admin jobs that could have caused the high read usage with this stackdriver filter resource.type="datastore_database"

Most common sources of unexpected usage include:

Use of managed imports and exports.
Reads ops resulting from active listeners (watch) during document change events.

You can also inquiry to GCP support for more information on the origin of the reads but this won't include too much details, it will only include number of ops per channel of origin (export, batch get document, change via watch, list collection ids, list docs, query, etc)

Per this other SO post its hard to know for sure the origin of the reads without implementing additional logic to keep track of them

Sudden spike in Firestore reads in Next.js app after no changes - please see graph

1 Answers1