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

[Architecture/Bug] 建立统一的后台资源生命周期管理，避免窗口关闭后残留进程

Abierto
  • ¿Algo no está bien?
#615 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
25/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust, typescript
Área
desktop, devtools

Línea de trabajo

Start in main.rs by tracing WindowEvent::Destroyed and RunEvent::Exit, then inspect the existing Run, Terminal, and Debug resource cleanup paths, including Windows process-tree termination. Define the shared owner and shutdown boundaries from the issue before connecting those entry points. Done means the listed acceptance scenarios pass, including multi-window isolation, idempotent cleanup, and force-cleanup fallback.

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

Descripción

area:run bug P1 review: high wait-Freezing

背景

#612 暴露了一个比 Spring Boot / Windows 单点问题更底层的生命周期缺口：Lithe 启动或持有的后台资源，没有统一绑定到 Window / Workspace / App 生命周期，在窗口销毁或应用退出时也没有统一回收入口。

当前已经存在按模块管理资源的能力，例如 Run 会记录运行会话并支持主动停止；但窗口关闭、应用退出与 Run / Terminal / Debug 等资源的清理并未形成统一生命周期链路。随着后续 LSP、MCP Server、Agent 等长期后台进程增加，如果继续由各模块零散处理，很容易再次出现 orphan process / 端口占用 / 后台服务残留等问题。

已知复现：#612

根因

当前资源管理更接近：

Window / App

Run        Terminal        Debug        ...
 |            |              |
各自管理     各自管理        各自管理

缺少统一的 owner 与 shutdown 语义：

  • 资源由哪个 Window / Workspace / App 拥有？
  • Owner 销毁时谁负责通知资源退出？
  • 正常退出失败时是否有统一的强制清理兜底？
  • 多窗口场景下如何只清理当前窗口拥有的资源？
  • App Exit 时如何保证所有资源最终被回收？

目标

建立统一的 Resource Lifecycle / Resource Registry 基础设施：

App
└── Window / Workspace
    ├── Run Process
    ├── Terminal
    ├── Debug Adapter
    ├── LSP Server
    ├── MCP Server
    ├── Agent Process
    └── Future Background Services

原则：

凡是由 Lithe 启动、持有或负责生命周期的长期资源，都必须有明确 owner；owner 销毁时必须被统一回收，不允许成为 orphan resource。

建议设计

1. 统一 Owner 模型

至少支持：

  • App
  • Window
  • Workspace（如后续需要）

资源注册时记录 owner，而不是只依赖各模块自己的 Map。

2. 统一生命周期入口

提供类似：

register(resource, owner)
unregister(resource)
shutdown_window(window_label)
shutdown_workspace(workspace_id)
shutdown_all()

窗口关闭只需要调用统一入口，而不是在 main.rs 里不断追加各模块 cleanup：

WindowEvent::Destroyed
  -> lifecycle.shutdown_window(window.label())

应用退出：

RunEvent::Exit
  -> lifecycle.shutdown_all()
3. 生命周期统一，但终止策略由资源自己负责

不同资源不能简单统一成 child.kill()：

Run
 └─ terminate process tree

Terminal
 └─ close PTY + terminate process tree

Debug
 └─ DAP disconnect / terminate
    └─ fallback force kill

LSP
 └─ shutdown -> exit
    └─ fallback force kill

MCP
 └─ graceful shutdown / close transport
    └─ fallback force kill

Windows Run 已有 process-tree kill 能力时应复用现有实现，不重复造一套。

4. 两阶段 Shutdown

建议统一语义：

  1. graceful shutdown
  2. bounded wait
  3. force cleanup
  4. unregister

并保证 cleanup 幂等，避免 Window Destroyed / App Exit / 手动 Stop 等路径重复触发时出现异常。

第一阶段范围

本 Issue 第一阶段建议先接入现有长期资源：

  • 建立 LifecycleManager / ResourceRegistry 基础结构
  • 定义 App / Window（必要时 Workspace）owner
  • 接入 WindowEvent::Destroyed
  • 接入 RunEvent::Exit 作为全局兜底
  • Run 接入统一生命周期
  • Terminal 接入统一生命周期
  • Debug 接入统一生命周期
  • Windows 下确保终止完整 process tree
  • 验证多窗口隔离：关闭 A 不影响 B
  • cleanup 幂等与重复触发安全

后续 LSP / MCP / Agent 直接复用该基础设施，不再自行设计窗口退出逻辑。

验收标准

  • Windows：运行 Spring Boot 后直接关闭对应窗口，原服务进程被回收，端口不再持续占用（覆盖 #612）
  • 关闭一个窗口只回收该窗口拥有的 Run / Terminal / Debug 资源
  • 退出整个 App 时所有由 Lithe 持有的后台资源都能被回收
  • 手动 Stop 与窗口关闭共用一致的底层终止能力，不出现两套逻辑漂移
  • 正常退出失败时有强制清理兜底
  • 多次 cleanup 不崩溃、不误杀其他窗口资源
  • 后续新增 LSP / MCP / Agent 等资源时，可以通过统一接口接入生命周期管理

关联

  • #612：Windows / Spring Boot 场景下关闭窗口后进程残留，是本问题的一个已知症状与验收用例。
Lenguaje dominante
TypeScript
Estrellas
1.8k
Forks
151
Merge medio
8 h 24 min
PR fusionados (30 d)
345

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 1lck/Lithe-IDEA

Todos los issues de 1lck/Lithe-IDEA

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.