[Bug] POST /search returns 500 with public collection IDs

[kaaloo]

Bug Report

Endpoint: POST /search
HTTP Status: 500 Internal Server Error
Date observed: 2026-02-28

Description

All search requests against the public collection IDs [784, 785, 1094, 783] return HTTP 500. The same collections work fine for document upload and the /rerank endpoint. The error is consistent — every question in a 5-sample evaluation batch failed with the same 500 response.

Request payload

{
  "prompt": "Comment le document indique‑t‑il que les risques sont présentés ?",
  "collections": [784, 785, 1094, 783],
  "limit": 10,
  "offset": 0,
  "method": "hybrid",
  "rff_k": 20
}

Response body

Internal Server Error

Reproduction

curl -s -X POST \
  -H "Authorization: Bearer $ALBERT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Comment le document indique-t-il que les risques sont présentés ?", "collections": [784, 785, 1094, 783], "limit": 10, "offset": 0, "method": "hybrid", "rff_k": 20}' \
  https://albert.api.etalab.gouv.fr/v1/search

Additional context

• Document upload to a private collection (collection 104880, created during the same session) worked fine immediately before this
• /rerank endpoint was not tested during this session but had been working in prior sessions
• Switching to method: "semantic" was not tested; the issue may be specific to hybrid
• All 5 evaluation questions against the same collection set returned 500 (not intermittent)

👾 Generated with Letta Code

[kaaloo]

Update: Looking at the 0.4.1 release notes, this may be related to the deprecation of prompt → query and collections → collection_ids in POST /v1/search. Our client is still sending the old parameter names. If the server already rejects them (or handles them incorrectly for hybrid search), that would explain the 500.

We'll update our client to use query and collection_ids. In the meantime, could you confirm whether the old prompt / collections parameters are still accepted on the currently deployed version, or whether the 500 is caused by something else?

👾 Generated with Letta Code

[leoguillaume]

@kaaloo The bug is not link to release (production of Albert API is still on 0.4.0post1). The problem is related to the timeout duration configured in production on Elasticsearch when calling collections that contain several thousand documents. I increase defaut timeout for the next production deployment (9 mars).

[kaaloo]

@kaaloo The bug is not link to release (production of Albert API is still on 0.4.0post1). The problem is related to the timeout duration configured in production on Elasticsearch when calling collections that contain several thousand documents. I increase defaut timeout for the next production deployment (9 mars).

Thanks for looking into this!