Summary
Every CLI command boots through materializeSinks in src/core/cli/dispatch.js, and any sink whose writer/destination plugin is not active in the short-lived CLI process emits a warning: sink '<name>' not materialized [sink_plugin_not_active] line to stderr (plus a hint line). On a fleet-managed install this fires for sinks like iceberg and central on every read-only command.
Example on hyp status:
warning: sink 'iceberg' not materialized [sink_plugin_not_active]: ...
→ expected for read-only commands (the writer/destination plugin for 'iceberg' isn't loaded here); the running daemon is unaffected
warning: sink 'central' not materialized [sink_plugin_not_active]: ...
→ expected for read-only commands ...
The hint text already admits these are expected for read-only commands and that the running daemon is unaffected, so emitting them at warning: level on every invocation is noise.
Why it matters now
The new configured-install entry (LLP 0011 "Returning to a configured install") prints a short friendly summary before its menu. These stderr warnings land right before that friendly screen and undercut it, especially on fleet installs where they always fire.
Where it lives
- Emitted in
src/core/cli/dispatch.js (~line 165), iterating sinkResult.errors from materializeSinks.
- Source of the
sink_plugin_not_active error kind: src/core/sinks/materialize.js (lines ~154, ~201, ~209).
Possible directions (not yet decided)
- Suppress (or demote to debug/structured-log only) the
sink_plugin_not_active kind for read-only commands, since it is expected by design.
- Keep it loud only when the command actually intends to write through that sink.
- Route it to dev telemetry rather than user-facing stderr.
Worth a small design decision since materialize warnings are intentionally surfaced for genuine misconfiguration; we only want to drop the expected-by-design case.
Summary
Every CLI command boots through
materializeSinksinsrc/core/cli/dispatch.js, and any sink whose writer/destination plugin is not active in the short-lived CLI process emits awarning: sink '<name>' not materialized [sink_plugin_not_active]line to stderr (plus a hint line). On a fleet-managed install this fires for sinks likeicebergandcentralon every read-only command.Example on
hyp status:The hint text already admits these are expected for read-only commands and that the running daemon is unaffected, so emitting them at
warning:level on every invocation is noise.Why it matters now
The new configured-install entry (LLP 0011 "Returning to a configured install") prints a short friendly summary before its menu. These stderr warnings land right before that friendly screen and undercut it, especially on fleet installs where they always fire.
Where it lives
src/core/cli/dispatch.js(~line 165), iteratingsinkResult.errorsfrommaterializeSinks.sink_plugin_not_activeerror kind:src/core/sinks/materialize.js(lines ~154, ~201, ~209).Possible directions (not yet decided)
sink_plugin_not_activekind for read-only commands, since it is expected by design.Worth a small design decision since materialize warnings are intentionally surfaced for genuine misconfiguration; we only want to drop the expected-by-design case.