firebase / firebase/firebase-tools
Firestore realtime query with Timestamp field in where clause behaves incorrectly on Emulator
- Dominant language
- TypeScript
- Stars
- 4.5k
- Forks
- 1.3k
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 84
Description
### [REQUIRED] Environment info
**firebase-tools:** 11.0.1
**Platform:** macOS
### [REQUIRED] Test case
If you open up a realtime listener that uses a timestamp in the where clause and then you proceed to update that timestamp field (even if the update still satisfies the where clause) the document is counted as removed from the listener and further updates to that document are no longer listened to.
### [REQUIRED] Steps to reproduce
1. Create a listener with a timestamp field in the where clause.
For instance `where('lastUpdated', '>', new Date(0));` <-- [Get documents older than epoch time]
2. Update a document in the collection by updating it's lastUpdated field to serverTimestamp() [which is obviously later than 1970]
3. The listener now reports that the document change is of type removed and it will not longer be listened to.
### [REQUIRED] Expected behavior
The document should remain in the result set if the where clause after the update is still true.
### [REQUIRED] Actual behavior
The document gets removed from the listener snapshot result set and does not come back in even though the where clause always remained satisfied. Looking at the Firestore emulator UI confirms the write was performed successfully and it should be included under the where clause condition.
It's worth noting I'm creating this bug report in this Repo because without changing the code at all in our application, using live "real world" Firebase has no issues. Another thing I'll note there is that logs seems to show that the document is actually also incorrectly removed on "real world" Firebase as well, but it's immediately added back!
Additionally it's worth noting it's required for our use case that the time in the document be updated using FieldValue.serverTimestamp().
Contributor guide
Assessment
This issue has not been assessed yet.