Skip to content

Get from server immediately after a document is updated gives old cached data when snapshot is open #6974

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rorystephenson opened this issue May 20, 2025 · 1 comment
Assignees

Comments

@rorystephenson
Copy link

rorystephenson commented May 20, 2025

Describe your environment

  • Android Studio version: Meerkat #AI-243.25659.59.2432.13423653
  • Firebase Component: Firestore
  • Component version: Using Flutter cloud_firestore 5.6.7

Describe the problem

NOTE: I have been directed to share this here after opening an issue in the flutter firebase sdk.

The short version is that when a snapshot listener for a document is already open and the app calls get(GetOptions(source: Source.server)) for that document, instead of fetching fresh data from the server cloud_firestore is returning the most recently fetched snapshot data. Moreover the isFromCache and hasPendingWrites metadata values are both false. This means we do not have a way to fetch fresh data from firestore when we know that there has been updated.

I believe this is a variant of this issue: firebase/flutterfire#10153. The difference being that our write is done by the backend. We have verified that the backend waits for the transaction to complete and that the mobile app waits for the backend to respond before calling get().

The linked issue has been closed as 'will not fix' using firebase/firebase-js-sdk#6915 (comment) as justification however this seems incorrect for the following reasons:

  • Firestore goes to great efforts to be a strongly consistent database that guarantees that reads which happen after a transaction is committed will return the latest data. What is the point of such a guarantee if the client short-cuts it by making it impossible to actually force a fetch of fresh data from the database.
  • The documentation for Source.server in GetOptions makes no reference to this behaviour.
  • In fact that same documentation emphasises that the data is being fetched from the server by mentioning that failure to fetch the data will result in an error. In my testing this does not happen, I can turn the internet off and the get() request returns the latest data from the snapshot listener.
  • The only workaround would seem to be stopping snapshots whilst performing the get(). In a large app which may listen to documents in various places for various reasons this is not feasible and amounts to maintaining a global state somewhere to make sure that snapshots are off before a given document is fetched via get() to be sure that the returned data is up to date.
  • Even if we didn't know that the data has just been changed for our purposes we still need to get the latest version of the data as we will be updating it via the backend API and we don't want to do that from stale data. Note that making the write from the frontend is not feasible as the backend needs to do checks on the data which the frontend cannot make.

Steps to reproduce:

Same as firebase/flutterfire#10153

In our case the transaction is run from a backend system but the outcome is the same.

@milaGGL
Copy link
Contributor

milaGGL commented May 21, 2025

Hi @rorystephenson , thank you for reporting this issue. Could you please help clarify what operations have been done, and what was expected? What do you mean by " We have verified that the backend waits for the transaction to complete and that the mobile app waits for the backend to respond before calling get()."? It would be nice if you can provide a minimal repro app with reproduction steps.

If you are trying to read from server, no cache involved, could you please try reading the doc inside a transaction? This might be the solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants