Registry Scheduling: startup logging goes to stdout, colliding with a stdout audit destination
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 88/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- backend, observability
Research direction
Start with crates/registry-scheduling/src/main.rs:7 and compare its tracing setup with crates/registry-relay-v2/src/main.rs:31-41. Configure audit.destination: stdout, start Scheduling, and verify stdout contains only valid audit JSON Lines while tracing output is on stderr. Done means the two output streams no longer interleave.
Written by the indexing model from the issue text.
Description
What (Registry Scheduling)
crates/registry-scheduling/src/main.rs:7 calls tracing_subscriber::fmt::init() unconditionally, as the first statement, with no .with_writer(...) override, so tracing logs go to stdout using the default plain-text formatter. Separately, AuditDestinationKind::Stdout (crates/registry-platform-audit/src/writer.rs:216-222) is a supported destination, and Scheduling's AuditConfig.destination (crates/registry-scheduling/src/config.rs:283-299, documented in products/scheduling/RUNTIME-CONFIG.md:84-92) allows audit.destination: stdout. Nothing checks or warns about this combination: RuntimeConfig::validate only validates the destination's own shape, and runtime.rs::open_audit just opens whichever destination is configured. When an operator selects a stdout audit destination, tracing's plain-text log lines and the audit writer's JSON Lines entries interleave on the same stream.
main.rs itself is unchanged by #1560 (its stdout logging predates this PR), but Scheduling's config previously required a mandatory file path for audit (path: PathBuf, no stdout option existed); #1560 added the destination enum with a stdout variant. So the collision this creates is newly reachable through this PR even though the logging call itself is old.
For comparison: crates/registry-relay-v2/src/main.rs:31-41 already sends its tracing output to stderr (.with_writer(std::io::stderr)) in install_operational_logging. crates/registry-evidence/src/main.rs:667-676 has the identical gap as Scheduling (also logs to stdout with no writer override), so this is not scheduling-specific, though this ticket is scoped to Scheduling since that is the assigned claim.
Found while reviewing #1560.
Why it matters
A stdout audit destination is meant to produce a clean JSON Lines stream for a downstream collector. Plain-text tracing lines mixed into that stream will not parse as audit entries; a lenient consumer might silently drop them (masking real log output) and a strict one might choke on the whole stream. Scheduling's formatter is plain-text rather than JSON, so the more likely failure is a JSON Lines consumer failing on non-JSON lines rather than a spurious line being misparsed as an audit record.
Suggested fix
Send tracing output to stderr unconditionally in main.rs, matching the pattern Relay already uses, regardless of which audit destination is configured. This avoids needing tracing initialization to depend on config having been parsed first.
How to test
Configure audit.destination: stdout, start the service, and assert stdout contains only well-formed audit JSON Lines while tracing output appears on stderr.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 5h 6m
- Merged PRs (30d)
- 170
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from registrystack/registry-stack
-
docs(breg): configure/breg.mdx lists stages for a request_lifecycle when, which bregctl refusesOpenagent-ready area:breg area:docs criticality:p3 documentation triage:needs-implementation
Difficulty 1/5 Under an hour Newbie friendliness 92/100
registrystack/registry-stack#1574 ·
Maintainers usually reply within 1 day
-
area:docs area:release criticality:p2 documentation triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
registrystack/registry-stack#1474 ·
Maintainers usually reply within 1 day
-
agent-ready area:evidence bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
registrystack/registry-stack#1449 ·
Maintainers usually reply within 1 day
-
agent-ready area:breg bug criticality:p3 triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
registrystack/registry-stack#1405 ·
Maintainers usually reply within 1 day
-
agent-ready bug criticality:p2 github_actions triage:needs-implementation
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
registrystack/registry-stack#1393 ·
Maintainers usually reply within 1 day
All issues in registrystack/registry-stack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
arkworks-rs/algebra#1161 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lbjlaq/Antigravity-Manager#3525 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Docs: "Work with Codex from anywhere" page still claims Windows mobile support is "coming soon"Openapp documentation remote windows-os
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oxidecomputer/dendrite#380 ·
Maintainers usually reply within 5 days