1.8 KiB
FAIL
crates/ely-platform/src/instance.rs:38 — 上一轮的 PID 归属竞争仍有残留：alive(pid) 只能证明进程存活，owner 随即把它当作当前持锁者。原子发布、死 PID 延迟发布单测和四进程并发单测均通过；但上次实例退出后，其遗留 PID 被其他进程复用，新实例取得锁、尚未 rename 时，第二份会报出那个无关进程。使用本轮构建的测试二进制调用实际 take：进程 64851 持有 instance.lock，预置存活的无关进程 64852，200 ms 后原子发布实际持锁者 64851；拒绝路径在 12 ms 即返回 process 64852，连续三轮均复现（另两轮为 64854、64856）。证据：/tmp/ely-x03-r2-live-stale.log。现有延迟发布单测本身也由测试进程持锁、另一个从未持锁的 sleep 提供期望 PID，覆盖不到归属校验。修复方向：让拒绝路径验证 PID 与本次锁持有者的关联，并以独立进程真实持锁、遗留 PID 仍存活的场景补回归测试。
crates/ely-platform/src/instance.rs:55 — Windows 的 alive 仅判断 PID 与自身不同，已退出的旧实例同样被判为存活，破坏本轮“等待存活的持锁者 PID”要求。具体场景：目录遗留已退出实例的 PID，新实例刚取得锁、尚未发布 PID，第二份会立即读取并报告旧 PID，跳过等待新 PID 的过程。将该函数原样提取编译，在 macOS 上执行其平台无关谓词：启动、终止并回收进程 65062 后，alive(65062) 仍返回 true，存活断言失败，退出码 101；证据：/tmp/ely-x03-r2-windows-predicate.log（此探针验证函数逻辑，未运行 Windows 原生环境）。修复方向：通过 Windows 进程 API 核验存活状态，并覆盖死 PID 延迟替换的 Windows 回归场景。