jackwener/maka-agent

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

Fermée

#2 514 ouverte le 8 août 2026

Voir sur GitHubGuide contributeur
 (1 commentaire) (0 réaction) (1 personne assignée)TypeScript (0 fork)github user discovery
bughelp wanted

Métriques du dépôt

Stars
 (1 étoile)
Métriques de merge PR
 (Aucune PR mergée en 30 j)

Description

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.

Guide contributeur

Direction de recherche
Commencez par reproduire localement le test instable pour observer la course. Lisez la logique de Stop et de timeout dans shell run manager. Identifiez où la cause du cycle de vie est validée. Au lieu de vous fier aux minuteurs réels, ajoutez un point de synchronisation explicite (par exemple, injectez une horloge ou utilisez de faux minuteurs) pour rendre l'ordre déterministe. Vérifiez que le test s'exécute de manière fiable plusieurs fois et que le contrat du cycle de vie reste inchangé.
Stack technique
nodejstypescript
Domaine
backendtesting
Type d'issue
Test
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitTypeScript
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
50