Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Registry Scheduling: startup logging goes to stdout, colliding with a stdout audit destination

オープン 初心者向け
  • 何か問題がありますか？
#1,583 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
88/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
backend, observability

調査の方向性

crates/registry-scheduling/src/main.rs:7 から始め、その tracing 設定を crates/registry-relay-v2/src/main.rs:31-41 と比較します。audit.destination: stdout を設定して Scheduling を起動し、tracing の出力が stderr に出力される一方で、stdout には有効な監査 JSON Lines のみが含まれることを確認します。2 つの出力ストリームが混在しなくなれば完了です。

索引モデルが issue の本文から書いたものです。

説明

agent-ready area:platform bug criticality:p3 rust triage:needs-implementation

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.

主要言語
Rust
スター
2
フォーク
0
平均マージ
5時間 6分
マージ済み PR（30日）
170

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

registrystack/registry-stack のほかの issue

registrystack/registry-stack の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。