[Firestore]
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- node.js, typescript
Research direction
Reproduce the report with the TypeScript Firestore query using Filter.or(), query.aggregate(), and AggregateField.average(), comparing it with query.get(). Start by tracing the aggregation path for disjunctive filters in the SDK and add a regression test covering documents with ratings 1 and 3. Done means the aggregate returns 2 while the existing query still returns both documents.
Written by the indexing model from the issue text.
Description
Step 2: Describe your environment
Operating System version: Ubuntu 24.04
Firebase SDK version: firebase-admin@13.5.0
@google-cloud/firestore version: 7.11.0
Firebase Product: Firestore
Node.js version: v20.19.0
NPM version: 11.3.0
Step 3: Describe the problem
When using AggregateField.average() on a query that includes Filter.or(), the aggregate returns an incorrect value. It seems to only consider one of the matching documents instead of computing the average across all matched documents.
Steps to reproduce:
Create a collection with documents containing a numeric field participantsRatingAvg
Query using Filter.or() combined with other where clauses
Use AggregateField.average("participantsRatingAvg") on that query
The result is incorrect
Sample code:
import { Filter, AggregateField } from "firebase-admin/firestore";
// Query with Filter.or()
const query = db.collectionGroup("events")
.where("participantsCount", ">", 0)
.where("activityId", "==", "some-activity-id")
.where("dateTime", ">=", startDate)
.where("dateTime", "<=", endDate)
.where(
Filter.or(
Filter.where("residenceId", "==", residenceId),
Filter.where("executionResidenceId", "==", residenceId)
)
)
.where("status", "in", ["accepted", "invoiced", "signed", "custom"]);
// First, verify the documents exist and their field values
const snapshot = await query.get();
console.log("Documents found:", snapshot.docs.map(d => ({
rating: d.data().participantsRatingAvg,
ratingType: typeof d.data().participantsRatingAvg,
hasField: "participantsRatingAvg" in d.data(),
})));
// Output:
// [
// { rating: 1, ratingType: 'number', hasField: true },
// { rating: 3, ratingType: 'number', hasField: true }
// ]
// Now run the aggregate
const aggregateSnapshot = await query.aggregate({
avgRating: AggregateField.average("participantsRatingAvg"),
}).get();
console.log("Average:", aggregateSnapshot.data().avgRating);
// Expected: 2 (average of 1 and 3)
// Actual: 3 (only considers one document)
Expected behavior:
AggregateField.average("participantsRatingAvg") should return 2 (the average of 1 and 3).
Actual behavior:
AggregateField.average("participantsRatingAvg") returns 3, ignoring one of the documents that matches the query.
Additional context:
The same query with .get() correctly returns both documents
Both documents have participantsRatingAvg as a number type (verified with typeof)
Both documents have the field present (verified with "field" in doc.data())
AggregateField.sum() and AggregateField.count() on the same query were not verified
The issue seems specific to queries using Filter.or() combined with aggregations
Workaround:
Fetch documents with .get() and compute the average manually:
const snapshot = await query.get();
const docs = snapshot.docs.map(d => d.data());
const validRatings = docs.filter(d => typeof d.participantsRatingAvg === "number" && d.participantsRatingAvg > 0);
const avgRating = validRatings.length > 0
? validRatings.reduce((sum, d) => sum + d.participantsRatingAvg, 0) / validRatings.length
: 0;
Best regards
- Dominant language
- TypeScript
- Stars
- 1.7k
- Forks
- 419
- Avg merge
- 3d 10h
- Merged PRs (30d)
- 16
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from firebase/firebase-admin-node
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
firebase/firebase-admin-node#3234 ·
-
firebase/firebase-admin-node#3221 · 3 comments · 1 assignee ·
-
api: messaging
Difficulty 3/5 1-2 days Newbie friendliness 70/100
firebase/firebase-admin-node#3215 ·
-
api: messaging
Difficulty 5/5 Over a week Newbie friendliness 28/100
firebase/firebase-admin-node#3214 ·
-
api: firestore type: feature request
firebase/firebase-admin-node#3183 · 1 comment · 1 assignee ·
All issues in firebase/firebase-admin-node
Similar issues
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GauravKarakoti/SecureFlow#1070 · 1 comment ·
-
feature:Languages/Translations good first issue ready Web
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
digitalfabrik/integreat-app#4394 ·