Decide whether the 8 macOS-skipped daemon-mode tests should be re-enabled (or the guard made explicit)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- リファクタリング
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
- 領域
- backend, testing-qa
調査の方向性
Start in hyperdb-mcp/tests/daemon_tests.rs, especially the eight macOS cfg_attr guards at lines 1469–1718, and review related reliability issues #286 and #300. Run the daemon tests on macOS under representative load and measure startup behavior; done means either reliable coverage on macOS with an appropriate timeout or an explicit, documented guard reason.
索引モデルが issue の本文から書いたものです。
説明
Decision needed
Eight daemon-mode integration tests in hyperdb-mcp/tests/daemon_tests.rs are skipped on macOS via:
#[cfg_attr(target_os = "macos", ignore = "flaky on macOS CI — daemon startup exceeds 150s timeout")]
They run on Linux and Windows CI — macOS is the only platform where they don't. This issue is to decide whether that guard is still warranted or should be lifted, rather than leaving it as a silent cfg_attr.
The eight:
daemon_mode_engine_connects_to_shared_hyperddaemon_mode_two_engines_share_same_hyperddaemon_mode_persistent_database_file_survives_engine_dropdaemon_mode_persistent_engine_data_is_queryablehyperd_monitor_detects_killed_hyperd_and_restartsclient_report_triggers_restart_after_killengine_recovers_after_hyperd_killeddaemon_mode_ephemeral_database_cleaned_up_on_drop
Why it matters
These cover the daemon's core value: shared-hyperd reuse across engines, persistence across engine drops, crash detection and restart, and ephemeral cleanup. Until recently all eight were unconditionally #[ignore]d, so the daemon shipped resident-by-default for months with no automated crash-recovery coverage. Re-enabling them on Linux/Windows immediately turned CI red and exposed a real endpoint-publish-ordering bug (fixed in #286). So the coverage is load-bearing — and macOS is currently the one tier not getting it.
The evidence on both sides
For lifting the guard: on an Apple M3 Max these run in ~15–22s each, nowhere near the 150s budget. The reason string blames "daemon startup exceeds 150s timeout," which does not reproduce on a normal local macOS run.
For keeping it: the flakiness was observed specifically on shared/loaded CI runners. When macOS-ignored tests were forced to run under load (load average ~4.8, another build in progress), daemon_mode_engine_connects_to_shared_hyperd failed with "TestDaemon did not start within 150s". macOS GitHub-hosted runners are slower and more contended than the Linux ones, so a budget that is generous locally can still be tight there.
Options
- Lift the guard, raise the budget. Re-enable on macOS with a longer or adaptive startup timeout (scale the 150s wait, or key it off observed CI slowness) so all three platforms get crash-recovery coverage. Risk: reintroduces macOS CI flakiness if the real problem is variance rather than the absolute budget.
- Investigate the macOS startup cost first. Determine why daemon+
hyperdstartup can exceed 150s on macOS runners (cold binary, code-signing/quarantine checks on first exec, runner I/O) before changing the guard. Most likely to produce a durable fix. - Keep the guard as a deliberate tradeoff, but say so explicitly in the reason string — "skipped on macOS CI runners due to startup variance; covered on Linux and Windows" — so it reads as a decision, not a suspected-stale workaround.
Recommendation: option 2 then 1 — measure the macOS startup path before widening the budget, since a 150s timeout that is already 7× the local runtime suggests the failure is a stall, not a slow-but-completing start.
Related recent daemon-test reliability items
- #286 — the endpoint-publish-ordering bug these tests caught once re-enabled on Linux.
- #300 — a separate shared-state flake in
daemon_tests.rs(scan_all_refused_returns_freeport_base). - #302 — Windows Named Pipe verification/perf, once the daemon moves to IPC.
Provenance
Raised while auditing the ignored-test surface. Verified against main at 8760df2: the eight cfg_attr(target_os = "macos", ignore) guards are at daemon_tests.rs:1469–1718.
- 主要言語
- Rust
- スター
- 3
- フォーク
- 2
- 平均マージ
- 23時間 11分
- マージ済み PR（30日）
- 65
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
tableau/hyper-api-rust のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
tableau/hyper-api-rust#294 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
tableau/hyper-api-rust#311 ·
メンテナーはふだん 1 日以内に返信
-
Windows Named Pipe: verify DACL denies other users, and measure read-path perf for MCP workloadsオープン
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
tableau/hyper-api-rust#302 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 72/100
tableau/hyper-api-rust#300 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
tableau/hyper-api-rust#299 ·
メンテナーはふだん 1 日以内に返信
tableau/hyper-api-rust の issue をすべて見る
似ている issue
-
C-bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
rust-lang/rust-analyzer#23501 ·
メンテナーはふだん 1 日以内に返信
-
Streamable HTTP client: a 401 or 403 with a JSON-RPC error body and no WWW-Authenticate loses its HTTP status対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug P2 ready for work T-security T-transport
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
modelcontextprotocol/rust-sdk#1339 ·
メンテナーはふだん 3 日以内に返信
-
scripts/gen-gallery.py:118: a ready session now reports in_progress, so SESSION_READY_OLD can goオープンnightly-audit
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
antithesishq/snouty#396 ·
メンテナーはふだん 1 日以内に返信
-
French BIP39 wordlist starts with a UTF-8 BOM, so generated French mnemonics carry U+FEFF and derive a non-canonical seed対応中かも @Kshot3000 が今日担当しました。 オープン
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
ergoplatform/sigma-rust#976 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信