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

Unify time mocking strategy across the codebase

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
説明が足りない
活発さ
静か
技術スタック
rust
領域
distributed-systems, testing

調査の方向性

まず crates/core/src/deadline.rs、crates/app/src/retry.rs、crates/core/src/qbft/fake_clock.rs、および issue に記載されているその他の影響を受けるファイルを読み、その後 PR #18 と #276 を確認します。既存の clock と injection のパターンを整理し、提案された代替案を評価したうえで、影響を受けるモジュール全体で一貫性がありテスト可能な time strategy を確立し、現在の timing flakiness をなくすことを完了条件とします。

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

説明

testing

Context

Time mocking has been flagged as a recurring pain point across multiple PRs:

  • PR #18 (QBFT): Tests were flaky due to reliance on real wall-clock time. cargo nextest was introduced specifically for timeout/retry control. A custom FakeClock was built for QBFT to work around the problem. Several tests remain #[ignore]d with timing-related failures ("wrong decide round", "wrong prepared value").
  • PR #276 (Deadliner): Utc::now() is called directly throughout deadline.rs, making the module untestable with tokio::time::pause()/advance(). Tests rely on real wall-clock time with short millisecond sleeps — fragile under CI load. The PR was merged with the agreement to revisit this as a separate issue.

Current state

The codebase has three unrelated time approaches coexisting:

Approach Where Mockable?
chrono::Utc::now() / chrono::Local::now() deadline.rs, retry.rs, peerinfo, cluster/definition.rs, p2p/k1.rs No (not controlled by tokio test-util)
std::time::Instant / tokio::time::Instant peerinfo/protocol.rs, p2p/relay.rs, QBFT tests Partially (tokio variant responds to pause()/advance())
FakeClock (custom, crossbeam-based) core/qbft/fake_clock.rs Yes, but ad-hoc and only for QBFT

Additionally, some modules use injectable time functions as a workaround:

  • retry.rs has with_time() accepting a Fn() -> DateTime<Utc> provider
  • deadline.rs has DeadlineFunc for injectable deadline calculation

These are local solutions — there is no unified abstraction.

Problem

  1. chrono::Utc::now() is invisible to tokio's test-util. tokio::time::pause() only controls tokio::time::Instant and tokio::time::sleep(). Any code using chrono::Utc::now() will see real wall-clock time in tests, leading to flaky or non-deterministic behavior.
  2. FakeClock is QBFT-specific. It uses crossbeam::channel and std::time::Instant — a completely different mechanism from tokio's async timers. It can't be reused for async code that uses tokio::select!.
  3. No consistent pattern for new code to follow. Each module has invented its own approach.

Proposed direction

Explore a unified time abstraction, potentially:

  • Option A: Lean into tokio::time throughout. Replace chrono::Utc::now() with tokio::time::Instant-based calculations where possible. Use tokio::time::pause()/advance() in tests. Keep chrono only for formatting/parsing, not as a clock source.
  • Option B: Create a small Clock trait (or crate-level abstraction as suggested in #276) that wraps the time source. Production uses real time; tests inject a controllable clock. This is more flexible but adds a layer of indirection.
  • Option C: Hybrid — use tokio's built-in mocking for async timer code, and a simple injectable Fn() -> DateTime<Utc> for code that needs wall-clock timestamps.

Affected areas

Key files using chrono::Utc::now() or direct time that would benefit from unification:

  • crates/core/src/deadline.rs
  • crates/app/src/retry.rs
  • crates/peerinfo/src/protocol.rs, config.rs, behaviour.rs
  • crates/cluster/src/definition.rs
  • crates/p2p/src/k1.rs
  • crates/core/src/qbft/fake_clock.rs (custom mock)
  • crates/app/src/privkeylock.rs

References

  • #18 — QBFT implementation (flaky tests, FakeClock introduction)
  • #276 — Deadliner (time mocking discussion)
  • tokio test-util docs
主要言語
Rust
スター
8
フォーク
6
平均マージ
4日 3時間
マージ済み PR（30日）
18

環境構築

はじめの一歩

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

NethermindEth/pluto のほかの issue

NethermindEth/pluto の issue をすべて見る

似ている issue

Rust の issue をもっと見る

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

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