Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#615 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
rust, typescript
領域
desktop, devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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 场景下关闭窗口后进程残留，是本问题的一个已知症状与验收用例。
主要言語
TypeScript
スター
1.8k
フォーク
151
平均マージ
7時間 51分
マージ済み PR（30日）
351

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

1lck/Lithe-IDEA のほかの issue

1lck/Lithe-IDEA の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。