fix(client): use 'estimate' serverTimestamps default in query/queryGroup

[detail-app]

Detail bug report: View on Detail

Bug

The client FirestoreService's runQuery helper (backs query and queryGroup) called queryDoc.data() with no options, falling back to the Firebase client SDK default serverTimestamps: 'none'. With that default, pending server timestamps — a document just written with FieldValue.serverTimestamp() while offline and read from cache — decode as null.

Every other read in the service (get, streamDoc, streamQuery, streamQueryGroup) uses the library-wide 'estimate' default via the dataOptions helper, so reading a just-written document through different methods disagreed: repo.getById() and repo.queryStream() succeeded while repo.query() / repo.group.query() raised a SchemaError (the null timestamp fails the model's required-timestamp schema, e.g. Firestore.DateTimeInsert). Introduced in 6ee2bc4, which added dataOptions but applied it only to the new streaming methods, leaving the pre-existing query on the SDK default.

Fix

runQuery now calls queryDoc.data(dataOptions()), restoring the documented 'estimate' default and consistency with the other reads. query/queryGroup don't expose FirestoreDataOptions on the FirestoreService interface, so the default is applied via dataOptions() with no argument — matching the existing contract while fixing the asymmetry.

The admin copy is intentionally left unchanged: @google-cloud/firestore's data() takes no SnapshotOptions and always returns resolved timestamps, so there is no pending-timestamp state to mishandle.

Testing

• Added unit tests asserting query, queryGroup, and get pass serverTimestamps: 'estimate' into snapshot.data(). The query/queryGroup cases fail without the fix (the option is undefined instead of 'estimate') and pass with it; the get cases anchor the cross-method consistency. (packages/client/src/lib/firestore/firestore-service.spec.ts)
• Routine checks: unit tests, lint, and build pass via pnpm nx affected -t lint test build; the client Firestore specs are green (34/34); the admin firestore-service.ts is untouched.
• End-to-end against a local Firestore emulator with the real firebase/firestore SDK: on the online happy path the four read methods agree (the server resolves the timestamp immediately so the bug is not observable while online) — confirms no regression.
• The offline / pending-timestamp scenario could not be fully reproduced end-to-end in this environment. Node has no IndexedDB, so the client SDK refuses persistence (failed-precondition); under jsdom + an IndexedDB shim, persistence enables but the SDK's offline write path hangs. The added unit tests cover the contract via the real service code with the SDK's data(options) pending-timestamp behavior simulated at the snapshot boundary — the only seam where 'none' returns null and 'estimate' returns a Timestamp.

Closes #104

---

Automatic Fixes PRs can be configured here.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the focused change aligns query decoding with the existing client read contract and is covered by deterministic regression tests.

Summary

This PR makes client-side query and queryGroup decode pending server timestamps using the library-wide estimate default.

• Passes dataOptions() to query snapshot decoding.
• Adds regression coverage for query, queryGroup, and default/explicit get timestamp options.

_{Reviews (1) · Last reviewed commit: "fix(client): use 'estimate' serverTimest..."}