Index not defined error, but on this case it should work

[marcusx2]

Operating System

macOS

Browser Version

Safari 16.5.2

Firebase SDK Version

10.7.0

Firebase SDK Product:

Database

Describe your project's tooling

index.html with source tag. Just javascript.

Describe the problem

I get the Index not defined error under a specific circumstance, but on another circumstance I don't. It's weird.

This is the data I use

const data = {
    "posts": {
        "ts-functions": {
            "metrics": {
                "views": 1200000,
                "likes": 251000,
                "shares": 100,
             },
             "title": "Why you should use TypeScript for writing Cloud Functions",
             "author": "Doug",
         },
         "android-arch-3": {
              "metrics": {
                  "views": 900000,
                  "likes": 117000,
                  "shares": 144,
               },
               "title": "Using Android Architecture Components with Firebase Realtime Database (Part 3)",
               "author": "Doug",
          }
    }
}

Steps and code to reproduce issue

Given the data above, the following code snippet does not trigger the error

set(ref(db), data);
let mostViewedPosts = query(ref(db, 'posts'), orderByChild('metrics/views'));
let snapshot = await get(mostViewedPosts);

However, the next one does trigger the error

await set(ref(db), data);
let mostViewedPosts = query(ref(db, 'posts'), orderByChild('metrics/views'));
let snapshot = await get(mostViewedPosts);

The only difference is that on the second code snippet, I await the set method. It doesn't make any sense that the error would happen only if I await the set. If anything, if the error had to happen at all it should happen if I don't await. This looks like a bug to me.

[jbalidiong]

Hi @marcusx2, thanks for reporting the issue. I was able to replicate the behavior. I'll inform our engineers about this to see if it's a bug or if something's missing in the code implementation. I’ll update this thread if I have any information to share.

[puf]

Hey @marcusx2. Thanks for the clear report. You're definitely hitting an an edge case here.

In the first code snippet, the local set operation completes and updates the local cache. This then allows the SDK being to satisfy the get call from its local cache, as it knows that it has a complete snapshot of data for all of db.

In the second code snippet, the await ensures that the code after it won't run until the write has completed on the server. At that point the SDK clears the local cache for the node that was written, and it will try to retrieve the information from the server next time it's needed. And at that point an index definition is required.

It is possible that the use-case works if you use onValue(..., onlyOnce: true) instead of get as that would use a different code path that did allow unindexed reads from the server. Without an index, the server would then return the complete unsorted/unfiltered data for the path, and the SDK would then perform the sort/filter step. We decided to not allow that for get() as it was often leading to developers unintentionally loading much more data than needed (and than they realized).

The problem should disappear once you define the index on the server. In general we recommend using realtime listeners rather than one-time reads as they remove many possible race conditions.