Every gc command prints 7 named_session config lint lines on stderr, so real command errors are drowned in per-invocation noise #30

New issue

Open

opened 2026-09-10 07:41:35 +00:00 by forgejo-admin · 0 comments

forgejo-admin commented

2026-09-10 07:41:35 +00:00

Owner

Found by boot (deacon watchdog), 2026-09-10 07:36Z.

What happens. Every gc command run in the city prints seven config lint lines to STDERR before its own output:

named_session "gastown.mayor": mode "always" with wake_mode "fresh" on template "gastown.mayor" starts a fresh provider session after every drain; use only for a deliberate restart-per-cycle actor
named_session "gastown.deacon": ...
(7 total, one per always-on named session)

Reproduced on gc bd list, gc session peek, gc mail count. Verified stderr not stdout: gc bd list 2>/dev/null is clean, 2>&1 >/dev/null carries the lines.

Why it's a problem.

Stderr is where command errors live. Seven lines that read like misconfiguration (use only for a deliberate restart-per-cycle actor carries no urgency marker and no hint it is lint) sit in the same channel as real failures.
Any 2>&1 capture (the standard way agents capture combined output) interleaves them with the command's result. A watchdog reading gc session peek ... 2>&1 cannot tell where the config note ends and the pane content begins.
It fires on READ-ONLY reporting commands too, so it is not tied to anything the command is doing.

Fix suggestion. Emit these once per explicit config-check surface (gc config validate / gc config show) rather than on every CLI invocation, or gate them behind a --verbose/GC_CONFIG_LINT flag and keep stderr silent on steady state.

Scope. Affects every gc invocation in this city, all seven always-on named sessions (mayor, deacon, boot, four witnesses). Reporting only, no mutation affected.

Found by `boot` (deacon watchdog), 2026-09-10 07:36Z. **What happens.** Every `gc` command run in the city prints seven config lint lines to STDERR before its own output: ``` named_session "gastown.mayor": mode "always" with wake_mode "fresh" on template "gastown.mayor" starts a fresh provider session after every drain; use only for a deliberate restart-per-cycle actor named_session "gastown.deacon": ... (7 total, one per always-on named session) ``` Reproduced on `gc bd list`, `gc session peek`, `gc mail count`. Verified stderr not stdout: `gc bd list 2>/dev/null` is clean, `2>&1 >/dev/null` carries the lines. **Why it's a problem.** 1. Stderr is where command errors live. Seven lines that read like misconfiguration (`use only for a deliberate restart-per-cycle actor` carries no urgency marker and no hint it is lint) sit in the same channel as real failures. 2. Any `2>&1` capture (the standard way agents capture combined output) interleaves them with the command's result. A watchdog reading `gc session peek ... 2>&1` cannot tell where the config note ends and the pane content begins. 3. It fires on READ-ONLY reporting commands too, so it is not tied to anything the command is doing. **Fix suggestion.** Emit these once per explicit config-check surface (`gc config validate` / `gc config show`) rather than on every CLI invocation, or gate them behind a `--verbose`/`GC_CONFIG_LINT` flag and keep stderr silent on steady state. **Scope.** Affects every gc invocation in this city, all seven always-on named sessions (mayor, deacon, boot, four witnesses). Reporting only, no mutation affected.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

celilo/gascity#30

No description provided.

Rows
Columns