GET /api/v1/packages/{name}/versions returns 500 for @openclaw/copilot, @openclaw/lobster, @openclaw/perplexity-plugin

[kip-claw]

Summary

GET /api/v1/packages/{name}/versions returns a 500 Server Error for a subset of published packages, while the same endpoint works fine for others. This surfaces in the OpenClaw Control UI's Plugins page as "Plugin details are unavailable" whenever the affected package is opened.

Reproduction

Direct, repeatable API calls (not routed through any client):

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40openclaw%2Fcopilot/versions"
500
$ curl -sS "https://clawhub.ai/api/v1/packages/%40openclaw%2Fcopilot/versions"
{"code":"[Request ID: 20f976a8aba3b9ff] Server Error"}

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40openclaw%2Flobster/versions"
500

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40openclaw%2Fperplexity-plugin/versions"
500

Each call returns a fresh Request ID, confirming the error is live and reproducible on demand, not a cached/one-off failure.

Not a universal outage

The general packages endpoint and most individual packages resolve fine:

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages"
200

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40openclaw%2Fgroq-provider/versions"
200

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40a2anet%2Fopenclaw-a2a-plugin/versions"
200

$ curl -sS -o /dev/null -w "%{http_code}\n" "https://clawhub.ai/api/v1/packages/%40taco-trade%2Fweb-copilot/versions"
200

So this isn't "the versions endpoint is broken" or "official packages are broken" as a class — @openclaw/groq-provider (also official) works. It's specific to at least these three packages:

• @openclaw/copilot
• @openclaw/lobster
• @openclaw/perplexity-plugin

I don't know what these three have in common that @openclaw/groq-provider doesn't (version count, presence of pre-release tags, changelog size, something in their metadata) — that's as far as I could narrow it down from the outside.

Client-side symptom

In the OpenClaw Control UI (macOS desktop app), opening @openclaw/copilot in the Plugins page shows:

Plugin details are unavailable: ClawHub /api/v1/packages/%40openclaw%2Fcopilot/versions failed (500): {"code":"[Request ID: 0ce4423b4af1d6a8] Server Error"}. Retry to reconnect to ClawHub.

(Different request ID than the one above — same error, reproduced independently twice, hours apart.)

Impact

Users cannot view plugin details, changelogs, or available versions for at least these three official plugins through the Control UI's Plugins page, and any client-side flow that depends on /versions for these packages (install-time version resolution, update checks) is presumably affected too.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 14, 2026, 1:48 PM ET / 17:48 UTC.

Summary
Current main still contains the pagination defect, and the linked fix PR remains open. Keep this issue until the repair lands and the affected package requests are verified.

Reproducibility: yes. at source level: a pending release followed by a published release with limit=1 reaches a second native paginate call in one query. This review did not execute that fixture or independently reproduce the named production requests.

Next step
Review and resolve #3691, then verify affected requests; an additional repair PR would duplicate the active work.

Review details

Best possible solution:

Filter eligible releases before one native pagination operation, preserving opaque cursors, legacy published releases, and existing visibility restrictions.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: a pending release followed by a published release with limit=1 reaches a second native paginate call in one query. This review did not execute that fixture or independently reproduce the named production requests.

Is this the best way to solve the issue?

Yes, filtering in the shared release query is the narrowest repair and preserves the existing API; returning partial post-filtered pages would leave additional pagination work to clients. The linked PR still needs its own runtime validation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The source-proven pagination defect has not been tied to production request traces for all three reported packages; other causes may remain after the repair.

Codex review notes: model internal, reasoning medium; reviewed against 8c2de6c506bb.

Label changes

Label justifications:

• P2: The report establishes broken version-history requests for a subset of packages, without establishing a general install or first-run outage.
• impact:ux-friction: Affected plugin details display an unavailable error instead of version history and changelogs.

Evidence reviewed

What I checked:

• Current-main defect: The checkout matches fetched main. paginatePublishedPackageReleases calls native paginate inside a loop, then filters unpublished releases. A non-final page containing filtered releases can trigger a second paginate invocation within the same query. (convex/packages.ts:1399, 8c2de6c506bb)
• HTTP failure path and dependency signal: The package versions route invokes listVersionsForViewerInternal, which calls the shared helper using Convex database pagination. This directly establishes the dependency on Convex's native pagination contract. (convex/httpApiV1/packagesV1.ts:4477, 8c2de6c506bb)
• Existing test permits the invalid operation: The pending-before-published fixture requests one result and explicitly expects two mocked paginate calls. It establishes the triggering data shape but does not enforce the native runtime restriction. (convex/packages.public.test.ts:7461, 8c2de6c506bb)
• Authoritative dependency guidance: Convex’s official pagination guidance explains that native pagination cannot track multiple pagination cursors in one query. This supports the source diagnosis; no dependency checkout or source commit was attributed.
• Existing version-history contract: The public API documents version history with a limit and continuation cursor. Publication filtering preserves legacy releases without publicationStatus while excluding owner-deleted and unpublished releases. (docs/http-api.md:827, 8c2de6c506bb)
• Open repair already owns the work: fix: show published versions after pending releases #3691 explicitly links this issue for closure and proposes filtering before one native pagination call. A live REST read confirms it is open and unmerged. Its supplied body reports focused regression coverage while acknowledging that production traces have not connected every reported 500 to this mechanism. (d53e80eda2b4)

Likely related people:

• Patrick-Erichsen: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.