Union multi-search fails for a collection that exists

Union multi-search fails with Collection having coll_id: N not found. for a collection that exists

Bug Description

A union multi-search (POST /multi_search with "union": true) sometimes fails with:

{"code":400,"error":"Collection having `coll_id: 346` not found."}

The collection is there. A federated multi-search (the same request without "union") returns its documents, and a single-collection search (POST /collections/<name>/documents/search) returns them too. Only the union request comes back empty.

Restarting the Typesense node fixes it for a while, and then it can come back. We have not lost any data.

We have only seen this on our production cluster.

Reproduction Steps

We cannot reproduce this on demand. It comes and goes on production, on individual nodes, and we have not found a request or data pattern that triggers it reliably. Restarting the node clears it for a while.

Expected vs Actual

Expected behavior A union multi-search returns the same documents as the same request without "union". If a collection is searchable on a node, union should find it there too.

Actual behavior "union": true fails with:

{"code":400,"error":"Collection having `coll_id: 346` not found."}

The collection is still searchable directly and without union.

Environment

• Typesense version: v30.2
• Operating system: Linux (Docker image typesense/typesense:30.2)
• Cluster: 3-node production cluster
• Client library: github.com/typesense/typesense-go/v4

Schema / Configuration

Collection schema involved:

{
  "name": "products",
  "fields": [
    { "name": "name", "type": "string" },
    { "name": "num_employees", "type": "int32" }
  ],
  "default_sorting_field": "num_employees"
}

Failing union payload:

{
  "union": true,
  "searches": [
    { "collection": "products", "q": "*", "query_by": "name" }
  ]
}

Working federated payload:

{
  "searches": [
    { "collection": "products", "q": "*", "query_by": "name" }
  ]
}

Additional Context

• The same request works against another node in the cluster.
• The error arrives inside an HTTP 200 response body, so a client that only reads hits gets an empty result set and no error.