scanMultipleProjects on workingDir="~" blocks event loop, causing daemon to appear hung

[lcy0108]

Summary

When workingDir is set to ~ (home directory) in bots.json, every new topic triggers scanMultipleProjects which synchronously scans the entire home directory tree (depth=3) for git repositories. This blocks the Node event loop for minutes, causing the daemon to appear hung — the process is alive, IPC is responsive, but no Lark WebSocket events are processed and no log output is written.

Root Cause

In daemon.js → handleNewTopic(), when pinnedWorkingDir is undefined (no oncall binding, no bot default dir), the code falls through to the repo selection branch:

const scanDirs = getProjectScanDirs(ds).filter(d => existsSync(d));
let projects = [];
if (scanDirs.length > 0) {
    projects = scanMultipleProjects(scanDirs, 3, repoPickerScanOptions());
}

With workingDir: "~", getProjectScanDirs() returns ["/Users/<user>"]. scanMultipleProjects is a synchronous function that recursively scans the entire home directory to depth 3, looking for .git directories. On a typical macOS home directory (containing node_modules, .cache, Library/, Chrome profiles, etc.), this scan processes tens of thousands of directory entries and blocks the event loop for several minutes.

During this blocking period:

• The daemon process is alive (ps shows it running, 0% CPU during I/O wait)
• PM2 reports online, 0 restarts
• IPC server (botmux send, botmux delete) still works
• But no Lark WS events are dispatched — the event loop is blocked
• No log lines are written after New session: / Created session
• The user's messages are never processed → bot doesn't reply

This is NOT a deadlock — it's synchronous CPU/disk I/O blocking. It mimics a hung process perfectly.

Reproduction

1. Set workingDir: "~" in ~/.botmux/bots.json
2. Restart daemon: botmux restart
3. Send any message (e.g. "hi") to the bot in a Feishu thread
4. Observe: daemon log stops after Created session <uuid>, no Worker forked line ever appears
5. botmux send --session-id <sid> still works (IPC is on a separate thread), but the bot never responds
6. Wait 5-10+ minutes — eventually the scan completes and the worker forks, but by then the user has given up

Diagnosis Trace

Added logger.info checkpoints around every await in handleNewTopic:

[handleNewTopic] pre-quota-check          ✓ (instant)
[handleNewTopic] pre-download             ✓ (instant)
[handleNewTopic] pre-resolveSender        ✓ (instant, 1ms)
[handleNewTopic] post-resolveSender       ✓ (instant, cached)
[handleNewTopic] pre-resolvePinnedWorkingDir ✓ (instant)
[handleNewTopic] post-resolvePinnedWorkingDir pinned=none  ← falls to else branch
[handleNewTopic] else-branch: pre-replyInvalidWorkingDirs  ✓ (instant)
[handleNewTopic] else-branch: pre-scanMultipleProjects scanDirs=/Users/daoke
  ← LOG STOPS HERE FOR MINUTES ←

Fix Applied (Workaround)

Changed workingDir from ~ to /tmp in bots.json. With /tmp (no git repos), scanMultipleProjects returns empty instantly → falls to the else (no projects) path → forkWorker fires immediately → bot responds normally.

- "workingDir": "~"
+ "workingDir": "/tmp"

Verification after fix:

[f031f6fe] Worker forked (pid: 42770, active: 1)              ✓
Session f031f6fe ready (no projects to select), total active: 1 ✓
[f031f6fe:out] Worker started, waiting for init...             ✓

Suggested Fixes

Any of these would prevent the issue:

1. Skip scan when workingDir is home directory — treat ~ / $HOME as "no repo scan, fork directly" (like the no-projects path)
2. Add a timeout to scanMultipleProjects — abort after N seconds and proceed with empty project list
3. Move scan to a worker thread — don't block the main event loop
4. Warn on workingDir: "~" at setup time — the home directory is almost never a useful repo scan root

Environment

• botmux v2.101.1
• macOS 14.3.0 (Darwin arm64)
• Node 22
• workingDir: ~ (home directory with ~50k+ files)

[lcy0108]

中文补充说明

一句话总结：bot 的 workingDir 设成 ~（home 目录）后，每次新话题都会同步扫描整个 home 目录找 git 仓库，把 Node 事件循环阻塞几分钟，daemon 假死——进程活着、IPC 通，但飞书消息完全不响应。

排查过程：

起初以为是僵尸会话堆积或 daemon 死锁，反复清理僵尸 + 重启都没用——每次用户发消息，daemon 日志停在 Created session 就再无输出。后来在 handleNewTopic 的每个 await 前后加诊断日志，逐步缩小范围：

1. resolveSender、resolvePinnedWorkingDir 都是瞬间返回（不是卡点）
2. pinnedWorkingDir=none → 走 else 分支（repo 选择 / 直接 spawn）
3. 日志停在 pre-scanMultipleProjects scanDirs=/Users/daoke → 卡在同步扫描 home 目录

关键误导点：

• daemon 进程 0% CPU、PM2 online、botmux send / botmux delete 全部正常 → 看起来像事件循环死锁
• 实际是 scanMultipleProjects 同步阻塞，扫描几万文件（含 node_modules、.cache、Chrome 配置等），数分钟才返回
• 飞书 WS 事件在事件循环里排队但无法被 dispatch，所以消息不丢但不处理

为什么定时任务没这个问题：

定时任务路径（executeScheduledTask）直接传 undefined 跳过了 getAvailableBots，且不经过 repo 扫描分支——它有明确的 task.workingDir，所以从不触发 scanMultipleProjects。这解释了为什么之前定时任务能正常推送、但用户发消息就卡。

临时修复：

bots.json 的 workingDir 从 ~ 改成 /tmp，扫描瞬间返回空，直接 forkWorker，问题消失。

建议作者修的方向（优先级从高到低）：

1. workingDir=~ 时跳过 repo 扫描，直接走 no-projects 路径 fork
2. scanMultipleProjects 加超时（如 3s），超时返回空
3. 扫描移到 worker thread，不阻塞主循环
4. setup 向导里对 workingDir=~ 给警告

另外我在本地给 getAvailableBots 里的 listChatBotMembers 加了 5s 超时兜底（Promise.race），防止类似的无超时 Lark API 调用挂起。这个补丁保留着了，如果需要可以提 PR。

[deepcoldy]

确实是个问题，新版在setup流程上做了优化，希望可以避免后续用户踩坑

[deepcoldy]

你说的超时兜底我有空也补下，之后也欢迎提PR