openclaw/clawhub
1
0
Fork 0
mirror of https://github.com/openclaw/clawhub.git synced 2026-07-21 19:25:25 -04:00
Code Issues 183 Packages Projects Releases 1 Wiki Activity

[PR #242] [CLOSED] fix: allow pending-scan skills to appear in search results #297

New Issue
Closed
opened 2026-02-15 17:16:44 -05:00 by yindo · 0 comments
yindo commented 2026-02-15 17:16:44 -05:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/openclaw/clawhub/pull/242
Author: @superlowburn
Created: 2/12/2026
Status: ❌ Closed

Base: main ← Head: fix/publish-search-visibility

📝 Commits (1)

  • 0006860 fix: allow pending scan skills to appear in search results

📊 Changes

1 file changed (+2 additions, -1 deletions)

View changed files

📝 convex/lib/public.ts (+2 -1)

📄 Description

Summary

  • Published skills with moderationStatus: 'hidden' and moderationReason: 'pending.scan' were invisible in search results
  • toPublicSkill() filtered out all non-active skills, including those being actively scanned
  • Now allows pending-scan skills to hydrate in search while still filtering manually hidden/malicious skills

Fixes #139

Root Cause

When a skill is published, it gets moderationStatus: 'hidden' with moderationReason: 'pending.scan'. The embedding is created and indexed correctly, but toPublicSkill() returns null for any skill where moderationStatus !== 'active', making newly published skills invisible until a moderator manually approves them.

On second publish (new version), the old version's embedding is archived (unsearchable) and the new one is still filtered — making the skill completely unfindable.

Changes

  • Modified toPublicSkill() in convex/lib/public.ts to allow skills with moderationStatus: 'hidden' AND moderationReason: 'pending.scan' to pass through the visibility filter
  • Skills hidden for other reasons (manually moderated, flagged as malicious) remain filtered

Test plan

  • Publish a new skill → verify it appears in search within seconds
  • Publish a second version → verify skill remains searchable
  • Manually hidden skills should NOT appear in search
  • Skills flagged by VT/LLM scan should NOT appear in search

🤖 Generated with Claude Code

Greptile Overview

Greptile Summary

This PR changes toPublicSkill() (convex/lib/public.ts) so skills in the temporary moderation state moderationStatus: 'hidden' with moderationReason: 'pending.scan' are treated as public for hydration/search results.

This integrates cleanly with the existing public-skill filtering pattern: search hydration (convex/search.ts) and public listing endpoints (convex/skills.ts, convex/stars.ts) already centralize visibility decisions via toPublicSkill(). The change remains narrow (only the hidden + pending.scan case is allowed) and the existing malware block (moderationFlags including blocked.malware) remains enforced.

Confidence Score: 5/5

  • This PR is safe to merge with minimal risk.
  • The change is a small, explicit adjustment to the central public-skill filter (toPublicSkill) and is consistent with how search/listing code paths already rely on that function. It preserves existing exclusion rules for other non-active moderation states and continues to block malware-flagged skills.
  • No files require special attention

Context used:

  • Context from dashboard - AGENTS.md (source)

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/openclaw/clawhub/pull/242 **Author:** [@superlowburn](https://github.com/superlowburn) **Created:** 2/12/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/publish-search-visibility` --- ### 📝 Commits (1) - [`0006860`](https://github.com/openclaw/clawhub/commit/000686057e441e7f14d52728442c43d373fa4234) fix: allow pending scan skills to appear in search results ### 📊 Changes **1 file changed** (+2 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `convex/lib/public.ts` (+2 -1) </details> ### 📄 Description ## Summary - Published skills with `moderationStatus: 'hidden'` and `moderationReason: 'pending.scan'` were invisible in search results - `toPublicSkill()` filtered out all non-active skills, including those being actively scanned - Now allows pending-scan skills to hydrate in search while still filtering manually hidden/malicious skills Fixes #139 ## Root Cause When a skill is published, it gets `moderationStatus: 'hidden'` with `moderationReason: 'pending.scan'`. The embedding is created and indexed correctly, but `toPublicSkill()` returns `null` for any skill where `moderationStatus !== 'active'`, making newly published skills invisible until a moderator manually approves them. On second publish (new version), the old version's embedding is archived (unsearchable) and the new one is still filtered — making the skill completely unfindable. ## Changes - Modified `toPublicSkill()` in `convex/lib/public.ts` to allow skills with `moderationStatus: 'hidden'` AND `moderationReason: 'pending.scan'` to pass through the visibility filter - Skills hidden for other reasons (manually moderated, flagged as malicious) remain filtered ## Test plan - [ ] Publish a new skill → verify it appears in search within seconds - [ ] Publish a second version → verify skill remains searchable - [ ] Manually hidden skills should NOT appear in search - [ ] Skills flagged by VT/LLM scan should NOT appear in search 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR changes `toPublicSkill()` (`convex/lib/public.ts`) so skills in the temporary moderation state `moderationStatus: 'hidden'` with `moderationReason: 'pending.scan'` are treated as public for hydration/search results. This integrates cleanly with the existing public-skill filtering pattern: search hydration (`convex/search.ts`) and public listing endpoints (`convex/skills.ts`, `convex/stars.ts`) already centralize visibility decisions via `toPublicSkill()`. The change remains narrow (only the `hidden + pending.scan` case is allowed) and the existing malware block (`moderationFlags` including `blocked.malware`) remains enforced. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk. - The change is a small, explicit adjustment to the central public-skill filter (`toPublicSkill`) and is consistent with how search/listing code paths already rely on that function. It preserves existing exclusion rules for other non-active moderation states and continues to block malware-flagged skills. - No files require special attention <!-- greptile_other_comments_section --> **Context used:** - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=a1d58d20-b4dd-4cbb-973a-9fd7824e1921)) <!-- /greptile_comment --> --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-02-15 17:16:44 -05:00
yindo closed this issue 2026-02-15 17:16:44 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
pull-request
Mirrored from GitHub Pull Request
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: openclaw/clawhub#297
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?