diff --git a/tests/restart-chaos/README.md b/tests/restart-chaos/README.md index b457d35b03f..dd4cf315ea9 100644 --- a/tests/restart-chaos/README.md +++ b/tests/restart-chaos/README.md @@ -337,6 +337,45 @@ Limits: - Combine K15 with `--adapters opencode` and `--daytona-reuse-lease` or `--daytona-warm` to match staging's workload mix. +### Long mid-tool redeploy (`--k15-hold-seconds`, T1, Runner logs) + +```sh +node cli/node_modules/tsx/dist/cli.mjs tests/restart-chaos/main.ts --env daytona --daytona-image $IMG --daytona-cpu 3 \ + --adapters opencode --workloads T1 --faults K15 --k15-hold-seconds 240-480 --concurrency 2 --tasks 4 --seed 9310 +``` + +A staging deploy usually lands mid-turn and keeps the server down for 4–7 +minutes. In staging class R, recovery then found the remote Runner gone +(`runner_remote_process_identity_unavailable`). + +- **`--k15-hold-seconds ` or `-`** (0–600 s) seeds each K15's + outage. The server stops with SIGTERM and stays down for the hold. Then the + next deploy generation starts. Without the option, a K15 restarts at once. + The range is drawn only for K15 cells, so other seeds keep their plans. +- **T1** (opt-in workload) has the agent run one shell command in the + foreground for about 100 s (50 ticks of 2 s). It then saves `brief`, whose + first line is `TICKS-=50`. Its fault window (35–80 s after launch) + lands while the tool runs in the sandbox. The window stays short of provider + shell-tool timeouts. +- **Runner evidence:** on a Daytona K15 wave, the harness captures every + started sandbox of the wave three times: + - right after the server stopped (`-stopped`); + - after the hold, just before the next deploy starts (`-before_start`); + - at wave end (`wave-end`). + + Each capture is written to `results//daytona-runner/