Skip to main content
← Back to list
01Issue
BugClosedSwamp ClubPublic
AssigneesNone

Relationships

#1024 `swamp extension search --channel beta|rc|stable` ignores the filter — all channels + the no-flag default return an identical result set

Opened by magistr · 7/7/2026

Summary

swamp extension search --channel <beta|rc|stable> returns the same result set regardless of the channel value — and it's identical to running with no --channel flag. The help text says the flag should "Filter by release channel: 'beta', 'rc', or 'stable' (default: stable only)", but it appears to be a no-op.

Environment

  • CLI version: 20260707.202458.0-sha.17103ab8
  • Account: magistr
  • Observed: 2026-07-08

Reproduction

swamp extension search --channel beta   --json   # -> names -> md5 30830504
swamp extension search --channel stable --json   # -> names -> md5 30830504
swamp extension search --channel rc     --json   # -> names -> md5 30830504
swamp extension search                  --json   # -> names -> md5 30830504

All four return the byte-identical 20-name list (same md5, same order), first three: @figura/cribl-stream, @jamesakeech/spotify, @jamesakeech/jellyfin-playback.

Expected

  • --channel beta → only extensions with a beta release
  • --channel rc → only extensions with an rc release (should be a small set — identical to stable is implausible since rc releases are rare)
  • no flag → "stable only" per the help text

Actual

The filter is ignored — every channel value, plus the default, returns the same result set. RC releases being rare, three identical sets across beta/rc/stable can't be a coincidence of overlap.

Impact

There's no way to enumerate beta/rc extensions from the CLI. Discovered while trying to audit which beta-channel extensions are unscored for Lab #1023 (beta-channel scoring) — this filter bug is the reason beta-only extensions can't be listed from the CLI, so it compounds that investigation.

02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

7/7/2026, 10:50:29 PM

No activity in this phase yet.

03Sludge Pulse
Editable. Press Enter to edit.

magistr commented 7/7/2026, 10:07:22 PM

Related finding on the same command — swamp extension search output projection is also incomplete (not just the --channel filter):

swamp extension search --json omits score, latestBeta, and latestRc from every row entirely — they are not present as keys (verified: 0 of 20 rows carry a score key). The full row projection is only:

name, description, repository, repositoryVerified, repositoryVerifiedUrl,
latestVersion, createdAt, updatedAt, platforms, labels, contentTypes

Consequences:

  • No CLI parity with the web browse view, which shows score badges — you can't see or sort extensions by score from the CLI.
  • Active trap for programmatic callers: row.get("score") returns None, which naively reads as "unscored" when the score was simply never projected. (This is exactly what led me to a wrong conclusion while investigating #1023 before I switched to per-extension swamp extension info.)
  • latestBeta/latestRc being absent means you also can't tell an extension's pre-release state from search output — which compounds the --channel filter being ignored (this issue): from extension search there's no way to know or filter by channel.

Suggested fix: include score, latestBeta, and latestRc in the search row projection, matching what swamp extension info already returns.

Filing as a ripple here rather than a new issue since it's the same command and the same "search projection/filtering is incomplete" root as this bug — happy to split into a standalone if you'd prefer to track it separately.

stack72 commented 7/7/2026, 10:50:26 PM

Extension search won't show that - you need to get that from extension info - we will not duplicate the data. Extension search is a way through the system for the agent to not have t deal with copious amounts of data before dialling into an extension

extension search now makes sure that channel is supported. This was a swamp clude error now a CLI error

Sign in to post a ripple.