Follow-up from #136.
runWithDevServerGuard now aborts with blocked: true, ranOperation: false when it cannot stop the dev server — that path is new, because before #90 was fixed stopProject effectively always claimed success, so a failed stop was unreachable.
src/app/api/projects/[id]/override-remove/route.ts:121 doesn't check blocked. It returns { success: true, output: guardOutcome.result ?? '' }, so an operation that never ran surfaces to the user as a success with empty output.
The sibling routes (update, cve-lite/[id]/fix, overrides/[id]/fix) should be audited for the same pattern — none of them branch on stopped either.
Two smaller items from the same review, worth folding in:
- A failed guard-stop leaves the server down. The abort takes an early return that skips the
finally calling deps.start, so a partially-stopped server is never restarted, and stopped: false is reported inaccurately.
shell: false projects are force-killed 500ms after releasing their port. When shell is false the tracked child is the server, so the process-exit grace period applies to a real graceful shutdown and truncates the 4s SIGTERM budget by 8x.
Follow-up from #136.
runWithDevServerGuardnow aborts withblocked: true, ranOperation: falsewhen it cannot stop the dev server — that path is new, because before #90 was fixedstopProjecteffectively always claimed success, so a failed stop was unreachable.src/app/api/projects/[id]/override-remove/route.ts:121doesn't checkblocked. It returns{ success: true, output: guardOutcome.result ?? '' }, so an operation that never ran surfaces to the user as a success with empty output.The sibling routes (
update,cve-lite/[id]/fix,overrides/[id]/fix) should be audited for the same pattern — none of them branch onstoppedeither.Two smaller items from the same review, worth folding in:
finallycallingdeps.start, so a partially-stopped server is never restarted, andstopped: falseis reported inaccurately.shell: falseprojects are force-killed 500ms after releasing their port. Whenshellis false the tracked child is the server, so the process-exit grace period applies to a real graceful shutdown and truncates the 4s SIGTERM budget by 8x.