Context
PR #2216 added a Refresh button to the Registry page (visible for custom registries) with a tooltip showing Source and Updated (the upstream last_updated timestamp). The button currently calls refetch() on the React Query hooks for GET /api/v1beta/registry/default and GET /api/v1beta/registry/default/servers.
Problem
The button is already in place, but for custom registries of type api / url the backend caches data in memory for 1 hour with no way for HTTP clients to bypass it. Clicking refresh fires the same GET requests again, the backend returns cached data, and last_updated does not change. The button works for local_path (file re-read every GET) but is effectively a no-op for api/url.
Tracked upstream: stacklok/toolhive#5266
What needs to change here
Once stacklok/toolhive#5266 lands, the refresh callback in renderer/src/routes/(registry)/-registry.route.tsx needs to pass the cache-bypass signal to the API. The exact shape depends on which option toolhive ships:
POST /api/v1beta/registry/{name}/refresh endpoint (option 1 in upstream issue) → call the new endpoint before the existing refetch()s.
?refresh=true query param on the existing GETs → pass it through the generated client options.
Cache-Control: no-cache header → set on the request headers for the refresh path only.
In all cases the button itself does not change — only what the refresh callback in -registry.route.tsx (lines 82–86) does before/during the refetch.
Tasks
Acceptance criteria
Dependencies
References
Context
PR #2216 added a Refresh button to the Registry page (visible for custom registries) with a tooltip showing
SourceandUpdated(the upstreamlast_updatedtimestamp). The button currently callsrefetch()on the React Query hooks forGET /api/v1beta/registry/defaultandGET /api/v1beta/registry/default/servers.Problem
The button is already in place, but for custom registries of type
api/urlthe backend caches data in memory for 1 hour with no way for HTTP clients to bypass it. Clicking refresh fires the same GET requests again, the backend returns cached data, andlast_updateddoes not change. The button works forlocal_path(file re-read every GET) but is effectively a no-op forapi/url.Tracked upstream: stacklok/toolhive#5266
What needs to change here
Once stacklok/toolhive#5266 lands, the refresh callback in
renderer/src/routes/(registry)/-registry.route.tsxneeds to pass the cache-bypass signal to the API. The exact shape depends on which option toolhive ships:POST /api/v1beta/registry/{name}/refreshendpoint (option 1 in upstream issue) → call the new endpoint before the existingrefetch()s.?refresh=truequery param on the existing GETs → pass it through the generated client options.Cache-Control: no-cacheheader → set on the request headers for the refresh path only.In all cases the button itself does not change — only what the
refreshcallback in-registry.route.tsx(lines 82–86) does before/during the refetch.Tasks
thv serveis not refreshed by CLI--refresh, and no API endpoint exists to refresh it toolhive#5266 to ship and confirm the chosen API shape.pnpm run generate-client).renderer/src/routes/(registry)/-registry.route.tsxto pass the new signal.renderer/src/routes/__tests__/registry.test.tsx.Acceptance criteria
api/urlreturns fresh data from upstream (verify by changing the upstream registry and confirming the tooltip'sUpdatedmoves forward after a click).local_pathis preserved.Dependencies
thv serveis not refreshed by CLI--refresh, and no API endpoint exists to refresh it toolhive#5266References
thv serveis not refreshed by CLI--refresh, and no API endpoint exists to refresh it toolhive#5266