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

fix(mcp): test timeout_seconds does not kill a hung test run, which blocks every later tool call

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

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

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

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
領域
cli, testing

調査の方向性

Start in lib/src/commands/test/test.dart, where timeout_seconds is forwarded as --timeout to flutter test, and in lib/src/mcp/mcp_server.dart, where the run Lock is held. Decide whether the whole run needs a wall-clock timer that kills the process tree and releases the lock, and whether the per-test option should stay separate. Done when a hung test returns a timeout error naming the timeout and a queued test call then proceeds.

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

説明

bug
Description

The MCP test tool documents timeout_seconds as:

Maximum seconds to wait for the test run before killing the Flutter test process.

In practice the value is forwarded as --timeout, which very_good test passes to flutter test as --timeout=<n>s (lib/src/commands/test/test.dart). That is package:test's per-test timeout, not a wall-clock limit on the run, and nothing kills the process when the time is up.

The MCP server also serializes tool runs with a Lock (lib/src/mcp/mcp_server.dart, "keeps at most one run in flight"). The lock makes sense, but together with the above it turns one hung test into a stall for the whole server. Every later test call from any client or subagent waits behind it with no upper bound.

I hit this with several agents sharing one MCP server. A widget test deadlocked inside tester.runAsync (an image load started in the fake-async zone and awaited from the real zone). The flutter_tester process sat at 0% CPU for more than twice the given timeout_seconds and was never killed, so every other agent's test call was queued indefinitely.

Steps To Reproduce
  1. In a Flutter package, add a test that never completes and never yields, e.g.: 
    testWidgets('hangs', (tester) async {
  await tester.runAsync(() => Completer<void>().future);
});
  2. Call the MCP test tool with timeout_seconds: 30.
  3. While it runs, call test again (for another package or another client).
  4. Observe that the first run is not killed after 30 s and the second call never starts.
Expected Behavior
  • timeout_seconds bounds the whole run: after that time the flutter test process tree is killed and the tool returns a timeout error that says it was a timeout.
  • The lock is released, so queued calls proceed.
  • If a per-test timeout is wanted as well, expose it as a separate option, or reword the parameter description so it doesn't promise a kill.
Additional Context
  • very_good_cli 1.5.0 (same code on main), Flutter 3.47.5, macOS.
  • Related: #1722 (classification of test failures as transient).
主要言語
Dart
スター
2.4k
フォーク
244
平均マージ
1日 4時間
マージ済み PR（30日）
25

環境構築

はじめの一歩

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

VeryGoodOpenSource/very_good_cli のほかの issue

VeryGoodOpenSource/very_good_cli の issue をすべて見る

似ている issue

Dart の issue をもっと見る

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

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