`$graphLookup` fails with "Unrecognized BSON data type code 0" when the collection has a wildcard index · Issue #805 · documentdb/documentdb · GitHub
Skip to content

$graphLookup fails with "Unrecognized BSON data type code 0" when the collection has a wildcard index #805

Open

Description

@KieranP

Describe the bug

$graphLookup over a collection that has a wildcard index fails with CommandNotSupported: Unrecognized BSON data type code 0. The same query succeeds once the wildcard index is dropped. The wildcard index is on an unrelated path, not on connectFromField or connectToField.

Environment

  • Operating system and version: documentdb-local Docker image, Debian GNU/Linux 13 (trixie), image ghcr.io/documentdb/documentdb/documentdb-local:latest (sha256:4a341daca29b…, DocumentDB 1.0.0), host macOS 26.6.2 with OrbStack (Docker 29.8.2)
  • PostgreSQL version: 17.11
  • Architecture: arm64 (aarch64)

Reproduction Steps

const t = db.getSiblingDB("repro_graphlookup")
t.people.insertMany(Array.from({ length: 20000 }, (_, i) => ({
  _id: i,
  manager_id: i > 100 ? Math.floor(i / 10) : null,
  custom: { dept: "d" + (i % 50), level: i % 5 }
})))

const pipeline = [
  { $match: { _id: 19999 } },
  { $graphLookup: { from: "people", startWith: "$manager_id", connectFromField: "manager_id",
                    connectToField: "_id", as: "chain", maxDepth: 5 } },
  { $project: { n: { $size: "$chain" } } }
]

t.people.aggregate(pipeline).toArray()        // OK
t.people.createIndex({ "custom.$**": 1 })
t.people.aggregate(pipeline).toArray()        // fails
t.people.dropIndex("custom.$**_1")
t.people.aggregate(pipeline).toArray()        // OK again

Expected behavior

The query returns the same result with or without the wildcard index ([ { _id: 19999, n: 3 } ]), as on MongoDB 9.0.4.

Actual behavior

With the wildcard index present:

MongoServerError[CommandNotSupported]: Unrecognized BSON data type code 0

Without it, or with only a regular index on manager_id, the result is correct.

Additional context

#769 item 1 reports the same error on $lookup and infers that a wildcard index on the foreign collection triggers it, without isolating it. In our testing, a plain $lookup and a let/pipeline $lookup into a collection with a wildcard index both worked on 1.0.0, while $graphLookup fails every time. This repro isolates the trigger.

Related: #769.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions