Skip to content

2.33.10

Choose a tag to compare

@github-actions github-actions released this 03 Oct 07:47
· 793 commits to main since this release
  • 48cc6c6: Report out-of-memory recovery truthfully (#2408). Each session exit is now completed only once: overlapping monitor ticks no longer post the same log and kill notice three or six times, or overwrite "recovering" with "❌ failed". An exit 1 under Docker's sticky container-wide OOMKilled flag is no longer called a kill. A deliberate solve stop (auto-restart, auto-resume or usage limit) no longer uses up the recovery budget. The default --session-kill-resume-attempts is now 3. When the AI tool itself is SIGKILLed (exit 137), solve posts a ⚠️ warning and resumes the same session in the same container instead of stopping. A recovered task is shown as ⚠️ "finished successfully after automatic recovery (automatic recoveries: N)". The Telegram message and /queue count the total active time and show 🔁 N, and a fresh recovery launch names the earlier execution logs. Kill notices no longer print [object Object] as the resume command, and the "backend is still alive" verbose line is printed once instead of on every poll.

    A rerun on 2026-10-03 showed the old behaviour once more: "Auto-restart 5/5 - limit reached" was recovered as an OOM kill and kept working in the background while Telegram said ❌. That log tail is now a regression test. On start-command 0.35.0 or later, a resource-limited session that is killed resumes in place, under the same execution id and log. Its CPU/RAM limits are re-asserted on the resumed container, and the disk usage so far is carried into its disk allowance. Every kill or OOM decision is logged as a session_kill_recovery_decision event, and an exit that is not recovered as a session_kill_not_recovered event. start-command is now 0.35.0, eslint 10.12.0 and secretlint 13.0.7. start-command's new --on-kill-resume stays unused until link-foundation/start#178 is fixed.

    An audit of every restart path closed the remaining gaps. A session killed after solve had already stopped on its own is reported, not recovered. An exit 0 under the sticky OOM flag stays a success. "No progress between sessions" and "SUBSCRIPTION/ACCESS UNAVAILABLE" also count as deliberate stops, and stop markers count only at the start of a log line, never inside quoted tool output. /stop with the root session id now reaches the recovery session that replaced it, so a user stop is not followed by another recovery. A resumed solve child killed by a signal no longer makes its parent exit 0.

Related Pull Request: #2409


npm version