mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-03 11:10:23 +02:00
286ed61bb0
* fix(agent): reap claude process group on cancellation (#5918) The Claude backend spawned its child with a bare exec.CommandContext, so cancellation SIGKILLed only the leader. On a resumed stream-json session (no wall-clock timeout) the MCP servers and tool subprocesses it spawned were orphaned and kept running — 64+ min in #5918 — while, under --max-concurrent-tasks 1, holding the only slot and starving the queue. Put claude in its own process group and drive a group-wide SIGTERM->grace->SIGKILL on cancel/timeout before closing stdout, mirroring the fix already made for codex (#4520) and opencode (#4533). Add claude_cancel_unix_test.go covering the graceful and SIGKILL-escalation paths. MUL-5288 Co-authored-by: multica-agent <github@multica.ai> * fix(agent): gate claude SIGKILL escalation on whole process group Review found the grace-window escalation keyed off procDone (leader exit), not the process group. A SIGTERM-ignoring descendant that does not hold claude's stdout lets the leader exit, closes procDone, and skips the group SIGKILL — leaking exactly the orphan #5918 targets. Escalate to a group SIGKILL unless waitProcessGroupGone confirms the whole group has exited within the grace window (matching codex). It returns as soon as the group empties, so the graceful path adds no latency. Add a mixed-signal regression: TERM-respecting leader + TERM-ignoring, stdio-detached descendant, which fails against the leader-keyed escalation. MUL-5288 Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>