#1555 extension search: channel-filtered results carry null version fields, and multiple --channel values collapse instead of unioning

Summary

swamp extension search is only trustworthy on the default (stable) channel. Two separate defects make its output unusable for answering "what version of this package is published on channel X":

1. A channel-filtered result carries no version data at all. Every entry returned with an explicit --channel has latestVersion, latestBeta and latestRc all null, even when swamp extension info reports a real version for that package on that channel.
2. Multiple --channel values are not unioned. Passing several collapses the result to a single channel's set, chosen by an undocumented precedence, so a caller asking for "everything on any channel" silently loses whole result sets.

Version: 20260807.031228.0-sha.9a36314e

Defect 1 — version fields are null in channel-filtered search results

Steps:

swamp extension search --collective magistr --channel beta --per-page 100 --json
swamp extension info @magistr/stripe-mpp --json

Actual — the search finds the package but reports no version anywhere:

search --channel beta  -> @magistr/stripe-mpp
     latestVersion = None
     latestBeta    = None
     latestRc      = None
extension info         -> @magistr/stripe-mpp
     latestVersion = None
     latestBeta    = 2026.08.01.1
     latestRc      = None

Control, same command without --channel — the version IS populated, for every one of the 52 results:

@magistr/musicbrainz latestVersion = 2026.08.07.1
@magistr/pihole      latestVersion = 2026.07.16.2
default-sweep entries with null latestVersion: 0

So the fields are populated on the unfiltered path and dropped on the filtered one. @magistr/stripe-mpp publishes to beta (it carries a .release-channel file) and genuinely has latestBeta = 2026.08.01.1.

Expected: a search result should carry the same latestVersion/latestBeta/ latestRc values as extension info for the same package. At minimum, the version for the channel being filtered on should be present — otherwise the filter returns a set of names with nothing usable attached.

Defect 2 — multiple --channel values collapse instead of unioning

--channel is a collecting option ("Filter by release channel", collect: true), which reads as "any of these". Measured against the same collective, where the three channels hold 52 / 1 / 0 packages for a union of 53:

The result is never the union (53) and never a plain intersection either — an intersection with rc would be empty, yet stable,beta,rc returns 1. Each multi-value result equals exactly one channel's set: stable,beta and beta,stable both return beta's set (order-independent, so it is not last-flag-wins), while rc,stable returns rc's empty set. The selected channel appears to follow a fixed precedence rather than the flags given.

Expected: either union the channels (the natural reading of a repeatable filter), or reject more than one value with an explicit error. Silently discarding 52 of 53 results is the worst of the three.

Why this matters

Together these make extension search unable to answer "is every version my repo declares actually published?" — the natural bulk query, since per-package extension info costs a fresh process launch each time (51 packages took over two minutes and timed out in CI).

Concretely: a beta-channel package is absent from the default search, and present but version-less under --channel beta. Both readings look identical to "never published". That misreading nearly produced a wrong backfill here today, and it is only avoidable by falling back to per-package extension info.

Related

#1272 is the same family — a beta-only package whose null stable latestVersion breaks swamp extension version — but a different command and a different symptom. #1023 and #1025 cover beta/rc packages in scoring. This one is about the search endpoint's payload and its channel filter.