Frontend: distinguish "search unavailable" (503) from a generic search error #34

New Issue

2026-06-04T10:54:36Z

logaritmisk commented

2026-06-04 10:54:36 +00:00

Context

The M5 search endpoint returns 503 Service Unavailable when Meilisearch is not configured (AppState.search == None), and 500 for an actual query failure. The frontend SearchPanel currently renders the same search.loadError ("Search is unavailable") message for any isError, so a transient backend error and a "search feature is turned off" condition look identical to the user.

Ask

In web/src/search/search-panel.tsx (and the useSearch hook in web/src/api/queries.ts if needed), distinguish the two:

On 503, show a calm, explanatory message: search isn't enabled on this server (it's an optional feature — Meilisearch not configured). Don't imply a transient failure or invite retry.
On other errors (500/network), show the generic retry-friendly error.

Notes

useSearch's queryFn currently throws a generic Error on error || !data. To branch in the UI, capture the HTTP status (e.g. throw a typed error carrying response.status, or expose it) so SearchPanel can render search.unavailable vs search.loadError.
Add a search.unavailable i18n key (en + sv) and a test that a 503 renders it (MSW handler returning 503).
Minor UX polish, not urgent — surfaced in the M5 final review.

## Context The M5 search endpoint returns **`503 Service Unavailable`** when Meilisearch is not configured (`AppState.search == None`), and `500` for an actual query failure. The frontend `SearchPanel` currently renders the same `search.loadError` ("Search is unavailable") message for any `isError`, so a transient backend error and a "search feature is turned off" condition look identical to the user. ## Ask In `web/src/search/search-panel.tsx` (and the `useSearch` hook in `web/src/api/queries.ts` if needed), distinguish the two: - On `503`, show a calm, explanatory message: search isn't enabled on this server (it's an optional feature — Meilisearch not configured). Don't imply a transient failure or invite retry. - On other errors (`500`/network), show the generic retry-friendly error. ## Notes - `useSearch`'s `queryFn` currently throws a generic `Error` on `error || !data`. To branch in the UI, capture the HTTP status (e.g. throw a typed error carrying `response.status`, or expose it) so `SearchPanel` can render `search.unavailable` vs `search.loadError`. - Add a `search.unavailable` i18n key (en + sv) and a test that a 503 renders it (MSW handler returning 503). - Minor UX polish, not urgent — surfaced in the M5 final review.

logaritmisk closed this issue

2026-06-04 15:40:21 +00:00

logaritmisk referenced this issue from a commit

2026-06-04 17:41:31 +00:00

fix(web): search 503 vs error (#34); terms/authorities list error states (#31); authority-tab a11y + dead keys (#32); authority-kind test (#37)

logaritmisk referenced this issue from a commit

2026-06-04 17:41:31 +00:00

merge: tier 2 papercuts (#22 #18 #9 #4 #34 #31 #32 #37)

Sign in to join this conversation.