Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Dev session cannot be killed: forceExit crashes on undefined `pipeline`, orphan watchdog loops forever

Cerrado
  • ¿Algo no está bien?
#507 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, cli

Línea de trabajo

Read packages/everything-dev/src/services/dev/session.ts around forceExit and pipeline creation, then inspect orchestrator.ts and the orphan watchdog. Reproduce by starting bos dev and killing its parent process. Done means the session exits cleanly on orphaning or repeated SIGINT without a recurring exception; the issue does not name a test to run.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Symptoms

Killing a running bos dev session (or orphaning it via the parent/wrapper dying) leaves a zombie orchestrator that spams this every 200ms and never exits:

[Dev] Parent process died — force exiting (orphaned service tree)
[Orchestrator] Uncaught exception: ReferenceError: pipeline is not defined
    at forceExit (.../dist/services/dev/session.mjs:237:3)
    at Timeout._onTimeout (.../session.mjs:246:4)

^C is also swallowed: the second SIGINT escalates into the same broken forceExit, so even repeated ^C just re-prints the error. Only an external SIGKILL (or closing the terminal) ends it.

Root cause — three stacked bugs

1. forceExit references pipeline out of scope — packages/everything-dev/src/services/dev/session.ts:

const forceExit = () => {
    controls?.restoreView();
    // @ts-ignore
    pipeline.flush();          // ← ReferenceError at runtime
    console.log("\n[Dev] Force exit");
    controls?.emergencyKill(); // ← never reached
    process.exit(0);           // ← never reached
};

pipeline is created inside the session's Effect.gen block (session.ts:182, per-fiber log pipeline); forceExit is defined at the outer wrapper scope where it does not exist. The // @ts-ignore silences the type error but not the runtime one. The crash happens before emergencyKill() and process.exit(0).

2. The orchestrator swallows the crash — orchestrator.ts:20 registers process.on("uncaughtException", (err) => console.error(...)), so the ReferenceError is logged and the process survives instead of dying.

3. The orphan watchdog re-arms forever — a 200ms setInterval compares process.ppid against the initial value and calls the broken forceExit on every mismatch → infinite crash/log loop.

Introduced

fbe6c6ff (2026-10-19, "refactor(everything-dev): domain-folder layout, Effect-native CLI split, dev-render DIP", #476) — the pipeline.flush() call in forceExit came with that refactor's scope reshuffle. Shipped in [email protected].

Repro

  1. bos dev in any v2 child app (observed on a v2-upgraded child running the rc.14 CLI).
  2. Kill the parent/wrapper process (or let it die) so the orchestrator is reparented.
  3. Watch the 200ms crash loop; ^C does not help.

Fix direction

  • Hoist the pipeline (or an activePipeline handle) to the wrapper scope — assign when created, clear at teardown — and make the kill unconditional:
const forceExit = () => {
    try { controls?.restoreView(); } catch {}
    try { activePipeline?.flush(); } catch {}
    console.log("\n[Dev] Force exit");
    try { controls?.emergencyKill(); } catch {}
    process.exit(0);
};
  • Belt-and-braces in orchestrator.ts: if an uncaught exception fires while a force-exit is in flight, process.exit(1) instead of swallowing it.

Workaround until fixed

External kill path (never goes through the in-process forceExit): bos kill --all, or pkill -9 -f "everything-dev.*dev".

Lenguaje dominante
TypeScript
Estrellas
5
Forks
3
Merge medio
10 h 12 min
PR fusionados (30 d)
102

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de NEARBuilders/everything-dev

Todos los issues de NEARBuilders/everything-dev

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.