URL Index Creation: __name__ field is not sorted in the same direction of the last sorted field in the index definition

[glumb]

Operating System

not applicable

Environment (if applicable)

not applicable

Firebase SDK Version

11.8.1

Firebase SDK Product(s)

Firestore

Project Tooling

doesnt matter but we use Webpack 5.98.0

Detailed Problem Description

According to https://firebase.google.com/docs/firestore/query-data/index-overview :

By default, the name field is sorted in the same direction of the last sorted field in the index definition

however, if I run this query:

import { getFirestore, collection, query, where, orderBy, limit, getDocs } from "firebase/firestore";

const db = getFirestore();

const auditLogRef = collection(db, "Auditlog");
const q = query(
  auditLogRef,
  where("tenantID", "in", ["IeZfE0yKWs0kGBl1IG5M"]),
  orderBy("_meta.dateCreated", "desc"),
  orderBy('tenantID', 'asc'),
  limit(50)
);

const querySnapshot = await getDocs(q);
querySnapshot.forEach(doc => {
  console.log(doc.id, doc.data());
});

firebase gives me a link to create this index:

Where __name__ is not sorted according to the last field in the index, which would be _meta.dateCreated:DESCENDING but sorted ASCENDING for unknown reason.

Why is this? By what rules is this sorting determined? We need to create the indexes programatically and therefore need to know what index is required.

Steps and code to reproduce issue

1. compose a query with a where-in+orderBy and orderBy instruction (on different field)
2. execute the query
3. click on the query create link
4. see that fierbase suggests name beeing sorted not according to the last index field

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[MarkDuckworth]

@glumb, you're right this does not match the documented behavior. I'm reaching out to the backend team to see if they can provide some clarity on the expected index.

Googlers see b/425992250

[MarkDuckworth]

The Firestore SDKs are adding __name__ as an order by in the query. The ordering will always match the last explicit sort order. In your case, that is tenantID ascending. This is an intended behavior to ensure the SDK and backend always produce the same sort order as queries executed against the SDK cache.

Since the tenantID field is also used in the query's filter, tenantID becomes the first field in the index. Making the order of fields in the index not match the order of fields in the order-bys.

The documentation you linked does not cover this implicit order-by behavior of the SDK. I think this is a source of confusion. We will work to improve this documentation.

We need to create the indexes programatically and therefore need to know what index is required.

The behavior of the SDK is deterministic, so you can rely on it to implicitly add __name__ to the order-bys, and the direction will match the last explicit order-by direction. However, you can always explicitly add orderBy('__name__', ...) and choose what sort order you want.