fix: skill catalog loses owner identity in API v1 - #3580
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
@goutamadwant is attempting to deploy a commit to the OpenClaw Foundation Team on Vercel. A member of the Team first needs to authorize it. |
|
Codex review: needs real behavior proof before merge. Reviewed September 11, 2026, 9:32 PM ET / September 12, 2026, 01:32 UTC (Revision 21). ClawSweeper reviewWhat this changesAdds publisher identity to skill catalog responses, aligns nullable version schemas, and displays owner-qualified CLI results while accepting older registry responses. Merge readiness⛔ Blocked before merge - 3 items remain This PR remains necessary: current main still has the catalog identity and nullability defects. No blocking code findings remain, including the previously reported legacy-registry compatibility issue, but real behavior proof is still required. Priority: P2 Review scores
Verification
How this fits togetherClawHub’s catalog API turns public skill records from Convex into paginated JSON consumed by registry clients. The CLI validates those responses and displays skill identities and versions. flowchart LR
A[Public skill records] --> B[Convex catalog query]
B --> C[Owner and public version projection]
C --> D[Paginated HTTP response]
D --> E[Client schema validation]
E --> F[CLI skill listing]
Before merge
Agent review detailsSecurityNone. Review metrics
Root-cause clusterRelationship: Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep owner resolution in the existing digest projection, publish a consistent nullable-version contract, and retain the CLI’s tolerant decoder for older registries. Do we have a high-confidence way to reproduce the issue? Yes, source establishes both defects: main omits owner identity and emits null versions that its shared schema rejects. No live reproduction was executed in this read-only review. Is this the best way to solve the issue? Yes, the patch uses the appropriate existing projection and decoder boundaries. Replacing the catalog endpoint or filtering every versionless skill would be broader and would change existing catalog behavior. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 8c2de6c506bb. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (20 earlier review cycles; latest 8 shown)
|
9df0733 to
01bc62c
Compare
Closes #3575
What Problem This Solves
Fixes an issue where API v1 skill-catalog consumers could not distinguish skills with the same slug when they belonged to different owners. It also resolves response validation failures for catalog entries that do not have a public latest version.
Why This Change Was Made
The canonical list response now includes the resolved
ownerHandle, represents an unavailable latest version asnull, and keeps the shared schema, generated schema package, and OpenAPI contract aligned. CLI explore output usesownerHandle/slugso current catalog identity remains unambiguous.The CLI supports configured custom registries that may still return the previous list shape. Its compatibility decoder therefore accepts omitted
ownerHandleandlatestVersionfields and falls back to slug-only and unknown-version display, while the canonical server and published API schemas continue to require owner-qualified identity and an explicit nullable version.User Impact
API and CLI consumers can identify every current-registry skill by its owner-qualified name, including across cursor pages and when different owners publish the same slug. Entries without a public version satisfy the documented response contract. Existing custom registries remain usable during a rolling upgrade instead of failing CLI schema validation.
Evidence
Before the fix, focused regressions showed that the HTTP list handler omitted
ownerHandleand the strict schema rejected an explicitlatestVersion: null. After the fix, a deterministic four-page catalog fixture validates every response againstApiV1SkillListResponseSchema, preserves two distinct owners sharing one slug, retains an exact SemVer build-metadata value, and accepts the final entry with no public version.A CLI compatibility regression parses the previous registry response shape without
ownerHandleorlatestVersion; a formatter regression proves explore output falls back to the original slug-only form. The canonical package schema remains strict and continues to requireownerHandleandlatestVersion.Validation after merging current
mainat8c2de6c5into signed head904a50622f3b9c081eaa3f4cec3cee081fee4e85:Results: focused CLI/schema tests passed (101/101), focused server/shared-schema tests passed (525/525), and the aggregate PR gate passed with the static audit, formatting, lint, dead-code analysis, 6,665 unit tests (3 skipped), package verification, production type/build checks, and secretless HTTP/CLI E2E coverage. The refreshed aggregate run used Bun 1.4.0; repository CI remains pinned to Bun 1.3.10.
The behavior proof uses deterministic handler and CLI fixtures. A live after-fix HTTP trace is unavailable because there is no configured local Convex deployment for this branch and the fix is not deployed to the public endpoint. Convex code generation was not required because no generated API signatures changed. The Vercel preview requires OpenClaw Foundation authorization, which is separate from the patch.
Disclosure: AI was used to understand the codebase and review the fix.