O vazamento de órfãos do Vitest

Numa noite de construção, a máquina ficou lenta de repente. O culpado: 16 workers órfãos do Vitest, cada um girando perto de 100% de CPU, vivos havia ~11 horas — e que continuariam vivos para sempre se ninguém os matasse à mão.

Repare na assinatura de um órfão: PPID = 1. Em sistemas tipo Unix, quando o processo-pai morre sem reapear os filhos, esses filhos são reparented (adotados) pelo processo init, cujo PID é 1. Ver vários node (vitest) com PPID 1 é o sintoma exato de que algo perdeu o controle da própria árvore de processos.

Este é o coração da lição. O vazamento precisou que as duas coisas fossem verdade ao mesmo tempo:

A interseção das duas causas sobrevivíveis é o estado imortal. Telemetria: o incidente real de 2026-06-23.

Um patch único não seria robusto: endureça só a config e um hang diferente ainda orfana; adicione só o wrapper e um hang dentro do grupo ainda trava um núcleo até o timeout de relógio. As duas camadas vão para o repo.

Duas camadas, uma por causa, mais o Proof Gate: 565 green e pgrep vazio.

// Anti-orphan hardening: a hung test (server/socket/MCP/interval/unresolved
// promise with no teardown) must FAIL on a bounded timeout, never hang a
// worker forever. The `forks` pool isolates hangs in child processes that
// Vitest force-kills on teardown, so a stuck file cannot pin a CPU core.
testTimeout: 15_000,
hookTimeout: 15_000,
teardownTimeout: 10_000,
pool: 'forks',

// detached:true => POSIX setsid => the child leads a NEW process group, so
// `kill(-pid)` reaches every descendant (vitest main + all tinypool forks).
const child = spawn(bin, args, { stdio: 'inherit', detached: true });

const killGroup = (signal) => {
  try { process.kill(-child.pid, signal); }   // PID NEGATIVO = o grupo inteiro
  catch { /* grupo já se foi */ }
};

const sweep = () => {
  try { execFileSync('pkill', ['-9', '-f', 'vitest'], { stdio: 'ignore' }); }
  catch { /* nada para matar — pkill sai != 0 quando não há match */ }
};

• detached:true → o filho lidera um novo process group (POSIX setsid), então um único sinal alcança todos os descendentes.
• process.kill(-child.pid, …) → o PID negativo sinaliza o grupo inteiro, incluindo os tinypool forks — nunca um PID nu.
• pkill -9 -f vitest (sweep) → pega qualquer coisa que já tenha escapado para o PID 1 (o caso de orfanação), então o vazamento não acumula entre execuções.
• Um SAFE_TEST_TIMEOUT_MS duro (default 600000 = 10 min) limita a execução inteira; um timeout sai 124. O mesmo kill+sweep roda na saída normal, em SIGINT/SIGTERM (que saem 130) e em erro de spawn.

# a verificação, conceitualmente
pnpm test:safe            # execução limitada no próprio grupo → 565 passed
pgrep -f vitest           # → (sem saída): nada vazou. ESTA é a prova.

Proof Gate · fronteira do processo   O vazamento é um bug de processos persistentes — por isso a prova tem de ser observada na fronteira do processo, não só no resultado dos testes. Esta é a disciplina do Proof Gate em uma frase: prove no limite real, nunca em "parece correto".