CLI System Check Enhancement

Enhancement request to extend the CLI system-check command to display the same data as the OSS system settings page.

Severity

P2 (Medium) — Operational improvement. Admins currently need the web UI for system health; CLI enables automation and headless monitoring.

Current State

The CLI system check (client/features/system-check/system-check.js) is a client-side browser check (browser compat, connection, location, permissions, camera, microphone, media). The server-side RPC (server/queue/rpc_server/SystemCheck.js) only has one action: systemCheck:getJanus for Janus echo test server selection.

The web system settings page (server/web/routes/systemsettings.endpoint.js) already assembles all the requested data by calling:

• serviceContainer.diagnostic.getDiagnosticData() — response times, queue lengths, sequelize stats
• getEnvInfo() from server/util/systemEnv.js — gated behind config.systemSettings.showEnvInfo

Diagnostic Data Shape (from server/diagnostic.js Diagnostic class)

getDiagnosticData() returns:

{
  cssRoundTripMs, convertRoundTripMs, cronRoundTripMs,
  backgroundRoundTripMs, mediaRoundTripMs,
  socketRoundTripsMs: { [socketId]: ms },
  queueLength: [{ type: 'server'|'client', key, messageCount, consumerCount }],
  sequelizeStats: { usage, size, borrowed, pending, available, max, min, spareResourceCapacity },
  overloadedQueue: string[],
  eventLoopDelay?: { min, max, mean, percentiles },
  availableCvServersPercent?: number,
  cssClientPingresult?: object
}

Key Finding

All requested data is already collected. RabbitMQ queue enumeration is already done inside Diagnostic.startRPCRoundTrip() (line 79-116) using ch.checkQueue(key) on queueConnectionPool.connections. No new RabbitMQ integration needed.

Affected Components

File	Role
server/queue/rpc_server/SystemCheck.js	RPC server — only has getJanus. Extend here.
server/diagnostic.js	Diagnostic class — getDiagnosticData() is the single source of truth
server/util/systemEnv.js	getEnvInfo() — collects OS, arch, node, java, libc, ffmpeg, openssl
server/web/routes/systemsettings.endpoint.js	Reference: shows how to assemble both diagnostic + env data
server/service/diagnostic.js	Socket.io broadcaster — emits diagnostic:updated to authorized clients
client/ui/pages/systemsettings/systemsettings.script.js	Frontend consumer — shows expected data shape and rendering logic

Related: vuer_oss, rabbitmq-communication

Implementation Checklist

• Add systemCheck:getDiagnosticData RPC action to SystemCheck.js — calls serviceContainer.diagnostic.getDiagnosticData()
• Add systemCheck:getEnvironmentInfo RPC action — calls getEnvInfo() from server/util/systemEnv.js
• Decide: respect config.systemSettings.showEnvInfo gate or always show in CLI (web uses this gate for the UI, but CLI is an admin tool — may not need it)
• Format CLI output (JSON or table) for scripting
• Consider whether diagnostic data needs a fresh tick or if cached values suffice for CLI use

Risks

Security

The web endpoint requires authorized Socket.io session on systemsettings page. RPC actions need equivalent auth check.

Data Freshness

Diagnostic.startRPCRoundTrip() runs on a timer (diagnostic.rpcRoundTripIntervalMs). CLI will get whatever the last tick produced. If diagnostic hasn’t started (no admin on systemsettings page), queue data may be undefined.

No New RabbitMQ Work Needed

Queue enumeration already happens in Diagnostic.startRPCRoundTrip() via queueConnectionPool.connections and ch.checkQueue(key). The queueLength array in diagnostic data already contains all server + client queues with message and consumer counts.