Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,765 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Ambito
cli, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).
Lingua principale
Dart
Stelle
2.4k
Fork
244
Merge medio
1g 4h
PR unite (30g)
25

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di VeryGoodOpenSource/very_good_cli

Tutte le issue di VeryGoodOpenSource/very_good_cli

Issue simili

Altre issue su Dart

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.