修复 AGC Direct 写通道项目锁零等待与持锁方不可诊断 #320

Merged

lhk229 merged 8 commits from fix/issue-318-direct-write-lock-wait into master 2026-09-10 21:43:38 +08:00

Conversation 3 Commits 8 Files Changed 15

+1262 -529

8 Commits

Author	SHA1	Message	Date
suzmii	ff42fff61c	按评审意见把写锁等待挪出 runtime worker 并收紧 wait_exhausted 记账 ... - agc_write_file 写路径改经 bridge_write_file_in_blocking_pool 走 tokio::task::spawn_blocking：有界等待是同步轮询（最多约 10 秒），直接在 async handler 里跑会占住 tokio worker，争用窗口内同一轮并行写多个文件时会波及共享同一 runtime 的只读端点与 UI 命令 - 新增用例用默认 current_thread runtime 加心跳任务锁住该性质；把 handler 临时改回同步直调时该用例按预期失败，确认有区分度 - project.write_lock.wait_exhausted 与终态改判一起改为只在真的等过（max_attempts > 1）时发生：hydrate 的单次试探不再写 waitedMs 近似 0 的“耗尽”日志 - 技术方案、decision-log、pitfalls 同步这两条，并补“同步有界等待不能直接跑在 async handler 里”的排障经验	2026-09-10 21:38:48 +08:00
lhk229	e8c5d2e247	Merge branch 'master' into fix/issue-318-direct-write-lock-wait	2026-09-10 21:13:23 +08:00
suzmii	71e9ad3133	修复锁失败终态判据漏传平台导致 CI 把权限改判成争用 ... - project_write_lock_permission_is_ambiguous 改为按平台加原始错误码判定（Windows 的 ACCESS_DENIED(5)）；只看 ErrorKind 在 Linux 上会得出相反结论：errno 5 在 Windows 是 ACCESS_DENIED、在 Linux 是 EIO - ProjectWriteLockFailure::Retryable 携带 platform，终态改判与争用文案都用同一次分类的平台，不再依赖宿主 errno 语义 - 终态投影用例显式用 Windows 平台构造失败并补 Unix 反例，两个平台上结论一致；CI 首次推送正是在此失败（2358 passed / 1 failed，left contention / right permission_denied） - pitfalls 补充“判据的每一环都要带平台”的排障经验	2026-09-10 20:46:10 +08:00
suzmii	06f738dc99	将项目写锁从 project/filesystem.rs 纯搬移到 project/write_lock.rs ... - 新建 project/write_lock.rs：取锁、等待分类、持锁方诊断、残留回收与 4 条锁用例整体搬移，逻辑不变 - project/filesystem.rs 只保留项目文件 IO（1533 → 680 行），锁相关常量、结构、进程判据与用例全部移出 - project.rs 注册 mod write_lock 并 pub(crate) use write_lock::*，crate::project:: 与 crate:: 既有路径不变 - windows_metadata_is_reparse_point 提为 pub(crate)，供 write_lock 复用同一条 reparse point 判据 - agent_db.rs 与 checkpoint.rs 的 PROJECT_FILE_FLAG_OPEN_REPARSE_POINT 导入路径改为 super::write_lock - 同步修正技术方案、Fast GDD 技术方案、decision-log、pitfalls 中指向锁实现的文件路径，并把“拆锁”从后续事项改为已完成	2026-09-10 20:12:28 +08:00
suzmii	8c639e5d13	修复项目写锁重试判据用一次元数据观察误判瞬时争用 ... - 项目写锁分类改为只按错误码判定重试性，不再用 path.exists() 决定“要不要等”：真机 6 万次建锁/删锁竞争实测 396-538 例命中“ACCESS_DENIED(5) + 目标不可见”，旧判据会让等待层立刻失败关闭，把毫秒级竞争换成更误导的 ACL 文案 - 新增 ProjectWriteLockFailure（Retryable / Terminal）与 acquire_project_write_lock_failure，有界等待改按类型分流，acquire_project_write_lock 退化为它的文案包装 - Windows 的 ACCESS_DENIED(5) 终态改判移到等待预算耗尽之后：只有真的等过预算且目标此刻仍不存在时才投影成权限拒绝，单次试探保持争用语义 - 锁分类判据改为平台参数传入（project_write_lock_open_failure_for），Linux CI 可覆盖 Windows 分支；替换原先只在 Windows 本地执行的分类用例 - 零等待入口在错误码不可区分时补一句“可能是删除挂起、删除拆链窗口或权限 / ACL 拒绝”，争用前缀逐字不变，调用方既有重试语义不受影响 - PROJECT_WRITE_LOCK_CONTENTION_PREFIX 收口 provider_recovery.rs、planning_session_v2.rs、direct_runtime.rs 三处手写文案 - project.write_lock.wait_exhausted 日志补 projection= 分类，attempts 记为实际尝试次数 - 同步更新技术方案、decision-log、pitfalls，并修正 ownerIsSelf 只比 PID 的表述	2026-09-10 20:07:28 +08:00
suzmii	59cab3d9fd	Merge remote-tracking branch 'origin/master' into fix/issue-318-write-lock-classification	2026-09-10 19:58:05 +08:00
suzmii	4ecab19429	修正 CI 权限用例在 root 容器下的前提并补平台无关的分类判据 ... - project_write_lock_does_not_project_permission_denial_as_contention 不再用 expect_err 断言“只读目录必须挡住取锁”：CI 容器以 root 运行，0o500 不生效，取锁会正常成功；此时跳过端到端前提 - 新增平台无关用例 project_write_lock_classifies_by_whether_the_target_exists：目标存在才是争用、目标不存在却创建失败是权限拒绝、NotFound 归其它 - 让权限分类判据在不依赖 ACL 环境的条件下也有回归护栏，避免只靠会被 root 绕过的端到端用例	2026-09-10 16:52:30 +08:00
suzmii	81c2389132	修复 AGC Direct 写通道项目锁零等待与持锁方不可诊断 ... - Direct 写路径（agc_write_file）改用统一的有界等待，与 file.write / file.patch / file.delete 同语义，同一轮并行写多个文件按同一把锁串行，不再在 24-42ms 内把重叠判成"项目正在被其他写操作占用" - create_new 失败拆成争用 / 权限拒绝 / 其它三类：锁文件不存在却仍创建失败不再投影成争用；sharing violation(32) 与 lock violation(33) 恒定归争用 - 争用错误与等待日志带上持锁方身份（commandId / pid / createdAt / ownerIsSelf），锁文件处于删除挂起或未写完时显式表达成"身份不可读" - ProjectWriteLockSnapshot 补 commandId 与 describe_holder()，沿用既有快照 + 字节 CAS 回收机制，不新增第二套回收判据 - 有界等待预算耗尽记 project.write_lock.wait_exhausted（含等待毫秒数），权限拒绝记 project.write_lock.permission_denied，争用不在零等待入口里逐次记账 - 新增同进程重叠写等待、同轮并行写、活外部进程持锁带身份、权限拒绝分类、ACL 拒绝不投影成争用五条回归用例 - 同步 decision-log、pitfalls 与技术方案文档	2026-09-10 16:30:22 +08:00