0

I am hitting quota limits just doing simple dev testing on one box/browser and wondering why Firestore wasn't figuring out that my data hasn't changed between full-collection reads, which should be easy to determine via a timestamp or counter - but it seems that it is doing this.

The issue is that I have verified that the the only returned snapshot (of the unchanged collection) has meta-data of fromCache:true, and I can also see in the Network tab that the offending data is not being transferred from the server.

However, each query (F5 page refresh, etc.) is apparently counting against my quota, which currently means I can only update my code (hot-module-reload) or refresh some other way about 8 times a day, as I'm doing a full read of one particular 3K doc sized collection on startup, along with smaller subscriptions as the app proceeds.

The docs say that cached reads should not count against the quota -- what am I missing?

TheLazyDogsBack
  • 197
  • 1
  • 11
  • `Example: (1) Collection A has 4321 records (2) Cache is empty (3) Subscribe w/o filter (4) data transferred from server (5) we get snapshot of 4321 docs, 4321 changes, fromCache:false (6) no updates during lifetime of subscription because data is static (7) Unsubscribe (8) Data has not changed on server (9) ReSubscribe (10) No new data from server (presumably last-updated timestamp check between clent and server) (11) we get a snapshot of 4321 records, 4321 changes fromCache:true (12) we don't get any follow-up snapshots, becuase the data has not changed` – TheLazyDogsBack Jan 15 '20 at 16:08
  • Please contact Firebase support directly if you have questions about billing, or the billing on your project doesn't make sense. https://support.google.com/firebase/contact/support – Doug Stevenson Jan 15 '20 at 16:30

2 Answers2

1

This behavior may be due to various factors such as the methods you are using as well as the cache settings you have for Firestore. For example, by default get() will always attempt to get the information from the server and if it can't it would use the cache. This is mentioned over at here.

It is hard to give more punctual advice as you did not share any code, however, I would recommend you to check the information here in order to get the data offline as well as other answers on Stack such as this one which has a very good explanation on these kind of behaviors.

Hope you find this useful.

rsalinas
  • 1,507
  • 8
  • 9
  • Thanks, @rsalinas. I have already viewed the pointers you mentioned. – TheLazyDogsBack Jan 15 '20 at 15:55
  • I have added a clarification comment above. I am not interested in "getting the data offline" -- I'm interested in the behavior of the cache in the online scenario, when there have been no data changes between subscription requests. It *appears* that this is exactly what is happening, as all the meta-data matches expectations and I don't see the data coming across the wire. The issue is that even given all of the above, I get 4321 "reads" (this is certainly a mis-leading term...) subtracted from my quota. – TheLazyDogsBack Jan 15 '20 at 16:09
  • Ok, wow. This appears not to be a technical issue, but a marketing one. I made no code changes, but upgraded from the free Spark plan to the paid Flame plan. Now *no* quota usage is reported for the same reads. Looks like this is a (apparently viable) way to get people to pay-up. I don't especially mind paying, but if this is indeed the issue, it's certainly not transparent in the docs. – TheLazyDogsBack Jan 15 '20 at 16:29
0

See last comment -- it appears that cached queries may count against quotas if you are using the free Spark plan.

TheLazyDogsBack
  • 197
  • 1
  • 11