jackwener/maka-agent

test(runtime): make the Stop/timeout lifecycle race deterministic

Offen

#2.514 geöffnet am 08.08.2026

Auf GitHub ansehenContributor Guide
 (1 Kommentar) (0 Reaktionen) (1 zugewiesene Person)TypeScript (0 Forks)github user discovery
bughelp wanted

Repository-Metriken

Stars
 (1 Stern)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

Problem

packages/runtime/src/__tests__/shell-run-manager.test.ts intermittently fails in CI at keeps the first committed lifecycle cause across Stop and timeout races.

The observed failure expected cancelled but received timed_out. Rerunning the unchanged job passed, which makes the current test timing-dependent and leaves ambiguity between a product race and a nondeterministic test setup.

Evidence:

  • CI run 31258873738 on PR #2472.
  • The first test_workspaces attempt failed in the Runtime suite; the failed-job rerun passed without a code change.
  • PR #1776 previously fixed a related but different Stop/timeout race.

Expected outcome

  • Establish whether the first committed lifecycle cause is violated or the test starts Stop too close to the timeout boundary.
  • Replace wall-clock scheduling with a deterministic synchronization seam where practical.
  • Preserve the intended lifecycle contract; do not weaken the assertion or add retries.
  • Verify the focused race repeatedly and keep the Runtime workspace CI stable.

Contributor Guide

Research-Richtung
Beginnen Sie damit, den fehlschlagenden Test lokal zu reproduzieren, um den Wettlauf zu beobachten. Lesen Sie die Stop und Timeout Logik im Shell Run Manager. Identifizieren Sie, wo die Lebenszyklus Ursache festgelegt wird. Verlassen Sie sich nicht auf echte Timer, sondern fügen Sie eine explizite Synchronisationsschnittstelle hinzu (z. B. eine Uhr injizieren oder Fake Timer verwenden), um die Reihenfolge deterministisch zu machen. Überprüfen Sie, dass der Test zuverlässig viele Male läuft und der Lebenszyklusvertrag unverändert bleibt.
Tech Stack
nodejstypescript
Domain
backendtesting
Issue Type
Test
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GitTypeScript
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
50