jackwener/maka-agent

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

Open

#2,514 opened on Aug 8, 2026

View on GitHubContributor guide
 (1 comment) (0 reactions) (1 assignee)TypeScript (0 forks)github user discovery
bughelp wanted

Repository metrics

Stars
 (1 star)
PR merge metrics
 (PR metrics pending)

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.

Contributor guide

Research direction
Start by reproducing the flaky test locally to observe the race. Read the Stop and timeout logic in the shell run manager. Identify where the lifecycle cause is committed. Instead of relying on real timers, add an explicit synchronization seam (e.g., inject a clock or use fake timers) to make the ordering deterministic. Verify that the test runs reliably many times and that the lifecycle contract remains unchanged.
Tech stack
nodejstypescript
Domain
backendtesting
Issue type
Test
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitTypeScript
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50