> ## Documentation Index
> Fetch the complete documentation index at: https://demo-travel.webbinghub.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Search pipeline: from one query to one merged list

> How Omnibeds searches every supplier at once: time limits, retries, circuit breakers, the cache, selling prices, streaming, and merging the same hotel across suppliers.

A search in Omnibeds asks every enabled supplier in parallel and streams each supplier's hotels to the screen as soon as they arrive. One slow or broken supplier never holds up the others. The orchestrator lives in `lib/orchestrator/` and the route is `POST /api/search/stream`.

## The pipeline

Step through what happens to one query.

Back
Next

## Protection settings

These values come from `lib/orchestrator/` and the suppliers' config files.

| Setting | Value |
| - | - |
| Time limit per supplier | 4 s by default; LiteAPI 12 s; RateHawk 25 s (its own 20 s search limit plus 5 s) |
| "Wait longer" | The agent can raise the limit for one search; it then applies to every supplier |
| Retries | Up to 2, with exponential backoff from 150 ms (factor 2, capped at 2 s) and full jitter |
| Circuit breaker | Opens after 3 failures in a row, tries again after 15 s (half-open), shared by every server instance |
| Cache | 5 minutes per supplier, query and data mode, in each server's memory |

### What is not retried

A retry only helps when the next attempt could succeed. Omnibeds does not retry:

* a timeout (the supplier already had its full time),
* a supplier that is down,
* a 4xx or a malformed answer, which won't change on retry and would spend quota on a live API,
* an expired session or offer, which the adapter already handled,
* a quota that is used up.

### What is not cached

An answer that carries a note is not cached, so the next search shows the full result. RateHawk uses this for hotels whose details are still loading. The cache is also skipped while a demo fault is switched on, so the fault is visible.

## Which suppliers are asked

The agency turns suppliers on and off in the admin panel. Hotelbeds and RateHawk are also only searched when presenter mode is unlocked; otherwise the request is refused with a plain message. See [Confidential suppliers](https://demo-travel.webbinghub.io/docs/suppliers/confidential.md).

## Merging the same hotel

Suppliers describe the same hotel differently. The screen groups supplier hotels into one card per real hotel, with every supplier's price on it. The matching rules are in `lib/mapping/match.ts`.

| Signal | Weight |
| - | - |
| Name similarity | 0.5 |
| Distance | 0.3 |
| Address | 0.1 |
| Stars | 0.1 |

* Two hotels more than 1.5 km apart are never the same hotel, whatever their names.
* A score of 0.78 or more merges them.
* A score between 0.60 and 0.78 that didn't merge another way goes to the review queue on the Mapping page, where someone approves or splits it.

| Step | What happens |
| - | - |
| 1 | The route checks the query and presenter mode, and picks the enabled suppliers. |
| 2 | Each supplier starts in parallel; the screen gets a start event per supplier. |
| 3 | The circuit breaker is asked first; an open breaker fails fast. |
| 4 | A cached answer under 5 minutes old is used if there is one. |
| 5 | The adapter searches, with a time limit and retries for errors that may pass. |
| 6 | Hotels get the agency's selling prices and stream to the screen. |
| 7 | Success or failure updates the breaker and the log; the screen groups the same hotel from several suppliers into one card. |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.