Persist POSIX process-tree settlement proof for interrupted release recovery

Cerrado
#14,012 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, linux, macos
Área
backend, devops

Línea de trabajo

Start with server/services/releaseCandidateSettlement.js and the Windows precedent in server/lib/windowsAgentProcess.js; then trace launch ownership in server/services/agentCliSpawning.js and server/services/agentTuiSpawning.js. Read server/services/releaseCandidateRecovery.test.js and server/lib/processCwdProbe.js to understand existing holds and limits. Implement persisted POSIX supervision and recovery evidence, then validate the specified crash, lineage, ownership, and retirement races with real native processes while preserving existing Windows authority.

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

Descripción

bug effort:xhigh model:heavy plan planner:gpt-6-1-sol

Problem

Interrupted release-candidate recovery now preserves the original physical checkout, frozen cutoff, release base, prepared version, promotion and private review evidence. The recovery service intentionally holds macOS/Linux with candidate-process-proof-unavailable: this tree has no durable POSIX proof that an interrupted publisher's entire process tree has settled.

An absent parent PID and an empty checkout-cwd scan do not exclude a detached or reparented descendant working elsewhere. Manufacturing a settlement receipt or recreating the candidate would violate the ownership contract. Missing historical physical-generation evidence remains an intended hold; this issue does not authorize reconstructing an earlier seed.

Evidence and scope

  • server/services/releaseCandidateSettlement.js checks the runtime/session/runner registries, then requires the Windows native supervisor's persisted receipt; POSIX is explicitly held.
  • server/lib/windowsAgentProcess.js binds owner, launch, native process creation identity and settlement records. Its native boundary test retains a hold while a detached descendant survives the parent's exit, and after supervisor loss.
  • server/lib/processCwdProbe.js observes only current working directories and intentionally cannot establish whole-tree settlement.
  • server/services/agentCliSpawning.js and server/services/agentTuiSpawning.js own the launch paths that need authoritative run lineage; server/services/releaseCandidateRecovery.test.js already exercises the POSIX hold and a Windows-native service transfer.

macOS is the primary supported interactive host. Linux server-side process lifecycle is supported; this is not a Linux-browser compatibility request.

Chosen next step

Add service-owned, persisted POSIX run supervision and settlement evidence at the supported release-agent launch boundaries, then consume it in the existing recovery service. Bind evidence to the exact agent/task/start and a non-reusable process-generation identity. Select and document the native mechanism for each supported POSIX host; an observation that cannot account for detached/reparented descendants remains a hold. Never substitute PID absence, age, terminal prose or a checkout-cwd scan for the required proof.

Acceptance criteria

  • A supervised macOS interrupted release can recover the same checkout after restart once its entire owned process tree is demonstrably settled.
  • Cover supported Linux server launches with equivalent evidence, or retain an explicit unsupported-proof hold with a documented native limitation.
  • A detached child outside the checkout remains a hold after its parent exits; an unrelated neighboring process is never terminated or adopted.
  • Missing/corrupt receipts, changed start/process identities, supervisor loss and ambiguous process lineage remain held; evidence is never backdated.
  • Prove the launch, interruption/restart, process-settlement, ownership-transfer and retirement/publication races at the public service boundary using real native processes. Preserve exact Git checks and the current private review/cutoff/version evidence.
  • Existing Windows recovery remains covered and unchanged in authority. No live release publication, tag mutation, second candidate or manual checkout cleanup is part of validation.

hardwareRequirements: []

Dispatch rationale: model:heavy for native process lineage and cross-run ownership; effort:xhigh for crash-safe settlement and concurrent recovery evidence.

Core recovery shipped in #14006. This issue owns the separable POSIX process-proof remainder. First-reservation provenance is independently tracked in #14005.

Refs #13944

Lenguaje dominante
JavaScript
Estrellas
38
Forks
32
Merge medio
45 min
PR fusionados (30 d)
992

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 atomantic/PortOS

Todos los issues de atomantic/PortOS

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.