[cboulay]

Targets dev.

Why INPUT_SETTINGS shows up as a publisher

A unit that exposes dynamic settings gets a publisher on <unit>/INPUT_SETTINGS, created lazily the first time one of its settings is patched — ezmsg routes the patch to the owning backend process, applies it, and publishes the result to that topic. After that one message it is idle forever.

It is a control-plane endpoint, but the publishers pane can't tell it apart from a data publisher. It sits there at 0.0 Hz, offering a profiling trace that can never produce a sample — which reads as a broken trace rather than an idle topic. That is exactly how it was found: someone attached a trace to INTENT_FEATURES/HUB1/SDA/INPUT_SETTINGS and got an indefinite "Waiting for trace samples on this publisher endpoint."

On the live pipeline that surfaced this, exactly one of 88 publishers was a settings channel, and the v1 UUIDs date it precisely:

endpoint	created
pipeline process	16:56:00
SDA/OUTPUT_SIGNAL	16:56:00 (with the process)
SDA/INPUT_SETTINGS	17:16:26 — 20 minutes later, when SDA was first patched

61 components had dynamic settings enabled; only the one that had actually been patched had the extra publisher.

Change

Hide topics ending in /INPUT_SETTINGS from the publishers pane, with Show settings channels in Publishers (debug) in global settings to bring them back (persisted with the rest of the global settings, so it survives reloads).

The predicate lives in utils/settingsChannel.ts so it is unit-testable and there is one place to extend if other control-plane topics turn up.

Verification

• npm test: 30 passed, including the new predicate tests (it must not match .../INPUT_SETTINGS_2 or INPUT_SETTINGS_MONITOR).
• npm run test:e2e: 25 passed, including two new tests driving the same fixture — the settings publisher is absent by default and visible with the toggle on, so neither can pass vacuously.
• tsc reports nothing new (the two pre-existing topologyFlowData.tsx errors on dev are fixed separately in fix: repair the frontend type build and check it in CI #6).

What I dropped, and why

I had proposed bundling a "reset trace state on reconnect" fix, on the theory that a dashboard restart leaves the dock falsely claiming capturing. I built it, then tested the premise, and it was wrong. With a live trace running I killed the dashboard and started a new one under the same browser session:

	frames after restart	dock
with the fix	90	capturing, plotting
without the fix	132	capturing, plotting

The capture lives in the ezmsg unit process, not the dashboard, and ttl_seconds is null — so the trace keeps running across a dashboard restart and any new connection picks the samples straight back up. The dock was telling the truth. I removed the code rather than ship a fix for a problem that doesn't exist.

There is a narrower case where the dock can lie: something else disables the capture (another dashboard client, or a stray trace-control request), and this client keeps showing capturing with no samples. A reconnect fix would not help there — detecting "no samples while capturing" would. Happy to add that if you want it, but it's the idle-publisher warning idea in another guise, which we agreed to skip.

Note on packaged assets

Source only — src/ezmsg/dashboard/_web is untouched here. It is rebuilt in #5/#8, and #6 adds a CI check that fails when it drifts. Rebuild it after this merges (cd frontend && npm run build && cd .. && uv run python -m ezmsg.dashboard.build_frontend) or let the stack carry it.

🤖 Generated with Claude Code