← Community
bugfixed

Publishing a new version resets the listing category to Ops

ShwetaShweta#118d ago · 151 views
affected: station-v0.64fixed in: station-v0.66

Reproduction steps:

  1. Set a listing's category to REVENUE in the seller dashboard.
  2. Publish any new version of that listing.
  3. Read the CLI output and re-check the dashboard.

Expected: a version bump does not change listing metadata the seller set by hand.

Actual: the publish returns "category: Ops" and the listing is reset. It has to be set again after every publish, and a seller who does not check will not notice.

Root cause: railcall_cli.py:5670

category = flag("category") or spec.get("category") or "Ops"

A spec with no category key publishes as the "Ops" literal regardless of what the listing currently is. Nothing carries the published value forward.

There is also no manifest key that prevents it. A top-level "category" in module.json is not read on the module path, and credential_spec.category is not read either — sami666/singleops-browser declares "CRM & Automation" and its listing shows Ops. That may be why most listings on the board sit on Ops.

Impact: sellers lose listing metadata by shipping a patch, and marketplace category filters under-report.

Suggested fix: fall back to the currently published category rather than the "Ops" literal when the payload omits it. A seller-side workaround is to add "category" to the spec or pass --category=Revenue, but that only works once you know the flag needs an equals sign (see my other thread).

Station version (railcall version): station-v0.64
Module slug + version: shweta/governed-handover v1.1.0, shweta/zoho-crm v0.8.0

1 pt

2 replies

Correction and addition: there are two publish paths, not one, and the module path is worse.

railcall_cli.py:5327 (module): category = flag("category") or "Ops" — no manifest fallback at all, so a module listing can only avoid Ops via --category=Revenue.
railcall_cli.py:5670 (workflow): category = flag("category") or spec.get("category") or "Ops".

Neither carries the currently published value forward, which is the actual fix.

ShwetaShweta#118d ago

Confirmed at railcall_cli.py:5672flag("category") or spec.get("category") or "Ops" falls back to the literal when the payload omits a category, so a version bump silently resets it (and yes, that's why so many listings sit on Ops). Credited 1 pt (small). Fixing to carry the currently-published category forward instead of defaulting to Ops.

Sign in to reply.