crates/aft/src/lsp/tsconfig_membership.rs has two bare eprintln!("PROBE3 …") calls on the membership hot path:
:72 eprintln!("PROBE3 no tsconfig root: file = {} canonical = {}", …);
:79 eprintln!("PROBE3 file = {} | canonical = {} | tsconfig_dir = {}", …);
They arrived in b0cab7b2 ("fix(context): normalize the status-bar filter root (verbatim class, #10)", Aug 6) alongside the real fix, and are present in v0.49.1, v0.49.2, v0.49.3 and main. v0.49.0 and earlier are clean.
Unconditional, no log level, no feature gate — one line per file per membership check.
Why this is worth more than "debug line left in"
In standalone mode it goes to a bridge stderr nobody reads. Under the subc daemon it lands in the shared journal, and the volume is not small. Last 24h on this box:
31,438 PROBE3 lines
2 [aft] callgraph store refresh failed: sqlite error: database is locked
That is roughly 1,300 lines/hour of unconditional output from one module in a multi-module daemon. The practical cost is that it degrades operational visibility for everything else sharing that journal — a supervised module exited abnormally (crash) module_id=X line now has to be found among the noise. We caught a claustrum crash-loop yesterday exactly that way, by sweeping journalctl --user -u ck-subc, and that sweep is measurably harder now.
Worth noting the class: this is another defect that standalone mode structurally hides and daemon mode surfaces immediately — same shape as the six-registration problem in #195, where a month of green standalone CI concealed something that broke within hours under the daemon. Debug output is harmless when it goes to a per-session stderr and load-bearing when it goes to a shared supervisor log.
Fix
Delete both, or gate them behind log::trace! / the existing slog_* macros so they honour log level like the rest of the file's diagnostics. Happy to send a PR if you want it as one — it is a two-line delete, so it may be faster for you to just drop it in the next train.
Reproduction is a box running aft as a subc module across three sessions; the count above is from journalctl --user -u ck-subc --since "24 hours ago" | grep -c PROBE3. The consumer-side session that flagged it can add detail if useful.
crates/aft/src/lsp/tsconfig_membership.rshas two bareeprintln!("PROBE3 …")calls on the membership hot path:They arrived in
b0cab7b2("fix(context): normalize the status-bar filter root (verbatim class, #10)", Aug 6) alongside the real fix, and are present in v0.49.1, v0.49.2, v0.49.3 andmain. v0.49.0 and earlier are clean.Unconditional, no log level, no feature gate — one line per file per membership check.
Why this is worth more than "debug line left in"
In standalone mode it goes to a bridge stderr nobody reads. Under the subc daemon it lands in the shared journal, and the volume is not small. Last 24h on this box:
That is roughly 1,300 lines/hour of unconditional output from one module in a multi-module daemon. The practical cost is that it degrades operational visibility for everything else sharing that journal — a
supervised module exited abnormally (crash) module_id=Xline now has to be found among the noise. We caught aclaustrumcrash-loop yesterday exactly that way, by sweepingjournalctl --user -u ck-subc, and that sweep is measurably harder now.Worth noting the class: this is another defect that standalone mode structurally hides and daemon mode surfaces immediately — same shape as the six-registration problem in #195, where a month of green standalone CI concealed something that broke within hours under the daemon. Debug output is harmless when it goes to a per-session stderr and load-bearing when it goes to a shared supervisor log.
Fix
Delete both, or gate them behind
log::trace!/ the existingslog_*macros so they honour log level like the rest of the file's diagnostics. Happy to send a PR if you want it as one — it is a two-line delete, so it may be faster for you to just drop it in the next train.Reproduction is a box running aft as a subc module across three sessions; the count above is from
journalctl --user -u ck-subc --since "24 hours ago" | grep -c PROBE3. The consumer-side session that flagged it can add detail if useful.