I have more than 52k hits on my small project which is using NextJS with Firebase 9.
I don't know what the problem is because the data I am using is very limited and I have only two snapshot listener and one Authentication feature. But somehow in just two days Firestore quota has exceeded and there are more than 52k READ hits.
I don't know why that happened because there are no memory leaks and I am also closing the API listeners which come attached with Firebase.
I am providing github link in case anyone wants to take a look https://github.com/jainChetan81/Todo-List
Attached screenshot of Firebase console:
Use of the Firebase console will incur reads. If you leave the console open on a collection or document with busy write activity then the Firebase console will automatically read the changes that update the console's display. Most of the time this is the reason for unexpected high reads. You can go through this answer. Also, currently there are no tools to trace the reads in Firestore. So to limit the Firestore database reads you have to configure security rules.
So, I would suggest you check your Firestore rules. And if not, it is better to contact Firebase Support as this kind of issue needs visibility into your project and they will have access to it.
I am having the same problem as you with my React app. The solution is to use the useEffect hook and call the function that requests for firestore collection;
useEffect(()=> {
getPosts();
}, []);
Related
In the last day, I have started having trouble with Cloud Firestore serving outdated data to my Flutter app running on android. I tried clearing the cache for the app, uninstalling/reinstalling with no success. Still Firestore kept serving the outdated data. Then I tried disabling persistence with the persistenceEnabled: false at startup. It stopped serving the outdated data, but now it doesn't return current data that should be returned! Any suggestions to check what might be going on?
Edit: I should mention that this is happening on a collectionGroup query for which the index has been built. I've checked the database rules, and there are not any denies or errors resulting from this query.
Turns out I changed one of my Collection group queries recently and needed to update the index. So if you have Cloud Firestore queries that are acting erratic like mine was, check out your logcat or console log for an error like this:
Unhandled Exception: [cloud_firestore/failed-precondition] Operation was rejected because the system is not in a state required for the operation's execution. If performing a query, ensure it has been indexed via the Firebase console.
Firestore is supposed to provide a URL to build the appropriate index, but in my case the URL did not appear so I had to add it manually.
is there any way in firebase or google cloud console to view the firestore document reads by source (admin or web sdk)? we had a massive spike and need this info to triage.
All options are listed on the documentation page on monitoring usage, but there is no view of what specific document caused the spike in reads. If you want such a thing, you'll have to build it yourself - which unfortunately won't help for this incident that has already occurred.
I'm trying to switch from SQLite to Cloud Firestore in my app. And ofcourse, I'm trying to reduce the number of reads from Cloud Firestore.
I get a stream from Cloud Firestore like this:
list = fireStore.collection('users')
.document('public')
.collection('info').orderBy("date")
.snapshots();
All the documents from the collection 'info' is to be read. When read for the first time, I'd like to force future reads to be from the cache. Until, let's say, 20 days has passed. Then I'd like to update the cache.
This is as I understand it, possible with DocumentReference.get() and Query.get() (click here to find out how), but as far as I have found out, not possible with my solution.
Do I need to change my approach and implement one of the methods above or is there a work around for stream as I've used it?
The snapshots method in FlutterFire is the equivalent of onSnapshot in the native SDKs. These methods listen for changes on both the local cache and the server, and cannot be configured otherwise.
The get() methods in the native SDKs and FlutterFire can be configured to get the document(s) from a specific source. So if you want to force reading from the local cache, you'll have to use get(GetOptions(source: Source.cache)).
An alternative approach could be to explicitly manage network access for the Firestore client.
Last couple of weeks, I have been Observing difference between number of writes in Firebase console Firestore Usage tab and Google cloud console Quota page.
Before that, The count fairly used to sync.
Number of writes in Firebase Firestore console usage tab: 9.2K
Number of writes in Google Cloud Console page, Quotas Page: 19307
Which is approximately double the number of writes in Firebase Firestore Usage Tab. Are there any Internal writes happening which google doesn't report?
Firebase Console Firestore Usage Tab Page
Google cloud Console Quotas page
I have attached the screenshots for the same.
Can anyone clear My Query. Is this a valid Scenario?
Note: I Don't have any other project linked to the platform.
From your first screenshot you can see at the top left written on the graph “Does not include Imports/exports and may not match billing and quota usage”. Moreover, Google public documentation states that the Firebase console includes a usage dashboard that shows Cloud Firestore reads, writes, deletes and other metrics over time.
As a result of how the dashboard computes usage, the numbers reported can differ from billing reports. The billing reports are the final usage numbers.
The usage dashboard does not include reads and writes from managed import and export operations.
So,I have to answer my question.
I've found out the root cause. Firestore FieldValue atomic operations causing the double writes.
This double writes happening with any SDK version even in Cloud functions Admin SDK.
I've skipped the use of atomic operations using FieldValue. All Fine now.
Firebase Support Investigating the Issue. Will update When I Got more Info from them.
Edit:2
Response from Firebase support:
"The two writes come from: 1) the initial write and 2) the transformation. This is not a bug, and what is shown in the Cloud console is correct. We do have an internal ticket now to make sure the Firebase console syncs up this information better, as well, so hopefully that'll help."
That means Fieldvalue functions to increment and array Union, servertimestamp will cause two writes and I also found that they are causing extra reads as well. I feel Firebase should reconsider their decision of not considering it as bug or atleast restructure this Atomic Operation. Let's Wait and See.
I am trying to identify the reason for an abnormally high firestore read count in my android and web app.
If there was a way to profile firestore, I could get an idea of which collection, or which user is causing this high read count, but currently there is no way to profile firestore.
I added a log entry to my android and web apps to log the read count to a remote server, so I can troubleshoot the issue. But this log doesn't match the actual read count I see in the firestore console, so it looks like I have missed to log some places where firestore is queried.
The reason why firestore hasn't provided a way to profile firestore is because it is technically difficult for them to do it with the high load, as I read somewhere. But, it shouldn't be hard to track the usage at client library level.
Does anyone know a way to get the usage statistics out of the firestore client library? Or any other way to troubleshoot this issue?
There is currently no profiler. Please contact Firebase support and file a feature request to vote for this. Also, they might be able to help you understand the traffic.