fix(retriever): compute document query embeddings off the event loop - #1662

DocumentHybridSearchRetriever calls embedding_model.embed() synchronously inside its coroutines. Every sibling in the codebase offloads that call; this one file does not.

Description

A local sentence-transformers model runs a synchronous forward pass taking tens to hundreds of milliseconds. Calling it directly from a coroutine stalls the event loop — and therefore every other request on that worker — for its duration.

The correct pattern is already established in four places:

app/retriever/documents_hybrid_search.py lines 91 and 225 were the two that were missed — the direct sibling of chunks_hybrid_search.py, in the same two methods.

Motivation and Context

Consistency with the pattern the rest of the retrieval layer already follows.

Please read this part before weighing the PR. I checked whether these lines are reachable today, and they are not:

• vector_search and full_text_search on this class have no callers anywhere in the repo.
• hybrid_search has exactly one caller, ConnectorService._combined_rrf, which always passes a precomputed query_embedding — so the if query_embedding is None branch does not execute.

So this is not a measured latency improvement, and I would rather say that up front than let the diff imply one. The value is that the file stops disagreeing with its four siblings, and the next caller to use these entry points does not silently reintroduce the stall. If you would rather delete the two unused methods than fix them, that is a reasonable alternative and I am happy to send that instead.

Screenshots

Not applicable — backend only.

API Changes

• This PR includes API changes

Change Type

• Bug fix
• New feature
• Performance improvement
• Refactoring
• Documentation
• Dependency/Build system
• Breaking change
• Other (specify):

Testing Performed

• Tested locally
• Manual/QA verification

uv run pytest -m unit: 2845 passed, same 7 pre-existing failures as dev on this machine (git-tree and PAT static tests, unrelated and failing before this branch).

Two tests added. They use a fake embedding model that blocks a real thread on a threading.Event, then assert the coroutine has not completed while it is blocked — so the assertion is that the loop kept running, not that a particular function was called. Stashing only the source change:

                                                    dev    this branch
test_vector_search_embeds_without_blocking...      FAILED     passed
test_hybrid_search_embeds_without_blocking...      FAILED     passed

Both hang until the 5s release timeout and then fail on dev, which is the stall itself being observed.

Checklist

• Follows project coding standards and conventions
• Documentation updated as needed
• Dependencies updated as needed
• No lint/build errors or new warnings
• All relevant tests are passing

What does not change

• Query semantics, ranking, RRF scoring, filters, and returned shapes are identical — only where the embedding is computed moves.
• chunks_hybrid_search.py and connector_service.py are untouched; they were already correct.
• No config, schema, dependency, or API change.

High-level PR Summary

This PR fixes DocumentHybridSearchRetriever to compute query embeddings off the event loop using asyncio.to_thread, matching the pattern already established in four sibling files (chunks_hybrid_search.py, connector_service.py, and chat retrieval). The fix prevents potential event loop blocking when embedding models perform synchronous forward passes that can take tens to hundreds of milliseconds. While the affected code paths (vector_search and hybrid_search without precomputed embeddings) are currently unreachable in production, this change ensures consistency across the codebase and prevents future regressions when these methods are used.

⏱️ Estimated Review Time: 5-15 minutes