Found while implementing #5529 (see PR #6135 reviewer notes).
The registry extension client and thv's embedded v0.1 handlers disagree on the list-endpoint wire contract, for both skills and plugins:
|
Client (pkg/registry/api/skills_client.go, plugins_client.go) |
Embedded handler (pkg/api/v1/registry_v01_skills.go, registry_v01_plugins.go) |
| Search param |
?search= |
?q= |
| Pagination params |
?cursor= + ?limit= |
?page= + ?limit= |
| Response metadata |
metadata.count + metadata.nextCursor |
metadata.total + page + limit |
Concretely: pointing SkillsClient/PluginsClient at a ToolHive embedded registry API (rather than toolhive-registry-server) means server-side search silently returns the unfiltered first page, and auto-pagination terminates after page 1 (client looks for nextCursor, handler never emits it) — silently truncating catalogs >100 entries.
The client contract matches toolhive-registry-server's API (which uses search/cursor/limit + count/nextCursor — see internal/api/x/skills/routes.go there), so the embedded handlers are the odd ones out. The plugins client/handler copied the skills pair verbatim, so both pairs need fixing together.
Proposed direction: align the embedded v0.1 handlers with the registry-server contract (search/cursor + count/nextCursor), or make the clients tolerate both shapes. Needs a compatibility pass first — check whether anything external already consumes the embedded routes' q/page shape (UI, docs, thv itself).
Refs: #5525 (epic), #5529, PR #6135.
Found while implementing #5529 (see PR #6135 reviewer notes).
The registry extension client and thv's embedded v0.1 handlers disagree on the list-endpoint wire contract, for both skills and plugins:
pkg/registry/api/skills_client.go,plugins_client.go)pkg/api/v1/registry_v01_skills.go,registry_v01_plugins.go)?search=?q=?cursor=+?limit=?page=+?limit=metadata.count+metadata.nextCursormetadata.total+page+limitConcretely: pointing
SkillsClient/PluginsClientat a ToolHive embedded registry API (rather thantoolhive-registry-server) means server-side search silently returns the unfiltered first page, and auto-pagination terminates after page 1 (client looks fornextCursor, handler never emits it) — silently truncating catalogs >100 entries.The client contract matches
toolhive-registry-server's API (which usessearch/cursor/limit+count/nextCursor— seeinternal/api/x/skills/routes.gothere), so the embedded handlers are the odd ones out. The plugins client/handler copied the skills pair verbatim, so both pairs need fixing together.Proposed direction: align the embedded v0.1 handlers with the registry-server contract (
search/cursor+count/nextCursor), or make the clients tolerate both shapes. Needs a compatibility pass first — check whether anything external already consumes the embedded routes'q/pageshape (UI, docs,thvitself).Refs: #5525 (epic), #5529, PR #6135.