Is there an existing issue for the same bug?
Environment
FULLTEXT2 shared-dev 多 CN campaign 20260920t065720z-campaign，EVENTUAL 一致性。run 目录：/home/sunyuze/ft2-runner/fulltext2-dev-incremental-v4-20260904/runs/20260920t065720z-campaign。以下为历史运行证据，不把当前本地源码候选当作故障部署版本。
Actual Behavior
**已证实的故障链：**在 20260920t065720z-campaign 的多 CN 环境中，Pod freetier-01-s16c64g-854877c9c-cn-gvhx9 的采集标签为 pool_phase=Idle，无当前 owner；但其他 CN 的远程锁 binding 仍指向它。历史 kube_pod_info 将 172.20.50.15 映射到该 Pod（UID d1ff351f-c9d6-485b-819f-b2f53fcc9ea5）；Operator 与锁服务日志中的 CN UUID 同为 61323136-6562-3964-3436-393562363564。6003 是本次失败的锁服务 RPC 端口。
2026-09-20 UTC 的时间线：
| 时间 |
原始记录 |
| 14:51:01 |
unit-agent 因节点整合选择迁移 gvhx9，记录 Pod is not managed by CNClaim, evict it gracefully；Operator 将 CN 标记为 draining |
| 14:51:17 |
Operator 请求 HAKeeper 移除该 CN 并移除 finalizer；CloneSet 记录成功删除 Pod，kubelet 记录停止主容器 |
| 14:51:17.947 |
gvhx9 自身记录收到 terminated 信号并开始关闭 |
| 14:51:17.997 起 |
CN g2hkm、dbbh6 向指向 gvhx9 的远程锁 binding 请求时出现 EOF、failed to lock on remote 和 172.20.50.15:6003 连接拒绝 |
| 14:51:28 起 |
本 campaign 的 documents 表 INSERT／UPDATE／DELETE 失败；harness 因事务结果未知终止，partial_gate=FAILED、transport_errors=6 |
因此，节点整合驱逐了仍被其他 CN 依赖的锁服务 CN，直接触发 DML 失败。这不是仅凭拓扑变化与错误时间接近作出的推测。尚未定位的是：故障部署版本为何在远程锁依赖仍存在时放行删除——是退出握手未覆盖该路径、内核完成条件过早，还是 binding 迁移／失效传播存在问题。
Expected Behavior
正常驱逐不能仅凭 CN 无客户端会话判断其可以退出。只要其他 CN 仍依赖其锁服务，就应保持该 CN 运行，直到锁依赖安全迁移并获得明确退出确认；无法确认时阻止删除。
Steps to Reproduce
- 核对 2026-09-20
14:51 UTC 的历史 Prometheus kube_pod_info{pod_ip="172.20.50.15"}，以及 unit-agent、Operator、Kruise、kubelet、gvhx9、g2hkm、dbbh6 的 Loki 日志。2026-09-21 的只读取证会话已完成上述关联；不需靠重跑 dev 才能确认本次触发链。
- 修复验证使用独立环境：让 CN A 无客户端会话但承载 CN B 的远程锁，再触发正常驱逐并执行真实 DML；断言锁依赖解除前主容器不退出、事务结果明确、超时不强删。此受控用例目前
NOT_RUN。
Additional information
已保存的只读历史证据：
| 文件 |
SHA-256 |
outputs/run-state.json |
8705b59ffc40fb221719087d7fb266445cf5bd3f9b58469c3f83291ebd1efefa |
outputs/topology-change.json |
8b75c92a22c753c3bcf4cfe4a2ba62007956f2d610acd776de0160745ad0e06f |
outputs/gate-overall.json |
39de2a14aba6a2557676abcff2549e3b58950ef42d90f04f178cb17db52b5948 |
**我们已尝试：**Operator 本地候选补了 drain 尝试持久化、实例核验和不确定状态下保留保护；内核本地候选补了实例绑定的 BeginDrain／QueryDrain。临时源码 workspace 的控制器／envtest／race 和内核定向测试通过。这些是本地候选验证，未部署到发生故障的环境。unit-agent 的交接／取消候选也已分析，但精确 cos 依赖不可得，本地测试为 BLOCKED_ENVIRONMENT。
**目前阻塞：**Operator 固定的 MatrixOne 依赖尚无新协议符号，独立构建失败；没有可发布的内核协议版本及旧／新二进制兼容证明，也未完成独立环境的真实双 CN 受控驱逐、部署和 QA。因此不能直接重跑正式 dev campaign。故障的直接触发链已确认，但故障版本究竟在哪一步过早放行锁服务退出，仍需维护方核对 drain 决策。
最近相关改动（截至 2026-09-23）：Operator #617 加固的是远程 pipeline 观测；MatrixOne #28115、#28343、#28474 处理已离开 lock owner 的事务围栏和旧 binding 恢复。它们均在本次 9 月 20 日故障前合入，不能视为已解决本次删除前安全确认。Operator 当前 main 仍有 drain 超时放行和 does not exist 错误放行分支；公开主分支尚未找到本次实例级 drain 修复。
旧 run 保留，不以新一次普通 dev 长跑替代受控回归。此 run 的 acceptance_gate=NOT_EVALUATED，不宣称完整产品验收。
Is there an existing issue for the same bug?
Environment
FULLTEXT2 shared-dev 多 CN campaign
20260920t065720z-campaign，EVENTUAL一致性。run 目录：/home/sunyuze/ft2-runner/fulltext2-dev-incremental-v4-20260904/runs/20260920t065720z-campaign。以下为历史运行证据，不把当前本地源码候选当作故障部署版本。Actual Behavior
**已证实的故障链：**在
20260920t065720z-campaign的多 CN 环境中，Podfreetier-01-s16c64g-854877c9c-cn-gvhx9的采集标签为pool_phase=Idle，无当前 owner；但其他 CN 的远程锁 binding 仍指向它。历史kube_pod_info将172.20.50.15映射到该 Pod（UIDd1ff351f-c9d6-485b-819f-b2f53fcc9ea5）；Operator 与锁服务日志中的 CN UUID 同为61323136-6562-3964-3436-393562363564。6003是本次失败的锁服务 RPC 端口。2026-09-20 UTC 的时间线：
gvhx9，记录Pod is not managed by CNClaim, evict it gracefully；Operator 将 CN 标记为draininggvhx9自身记录收到terminated信号并开始关闭g2hkm、dbbh6向指向gvhx9的远程锁 binding 请求时出现EOF、failed to lock on remote和172.20.50.15:6003连接拒绝documents表 INSERT／UPDATE／DELETE 失败；harness 因事务结果未知终止，partial_gate=FAILED、transport_errors=6因此，节点整合驱逐了仍被其他 CN 依赖的锁服务 CN，直接触发 DML 失败。这不是仅凭拓扑变化与错误时间接近作出的推测。尚未定位的是：故障部署版本为何在远程锁依赖仍存在时放行删除——是退出握手未覆盖该路径、内核完成条件过早，还是 binding 迁移／失效传播存在问题。
Expected Behavior
正常驱逐不能仅凭 CN 无客户端会话判断其可以退出。只要其他 CN 仍依赖其锁服务，就应保持该 CN 运行，直到锁依赖安全迁移并获得明确退出确认；无法确认时阻止删除。
Steps to Reproduce
14:51 UTC的历史 Prometheuskube_pod_info{pod_ip="172.20.50.15"}，以及 unit-agent、Operator、Kruise、kubelet、gvhx9、g2hkm、dbbh6的 Loki 日志。2026-09-21 的只读取证会话已完成上述关联；不需靠重跑 dev 才能确认本次触发链。NOT_RUN。Additional information
已保存的只读历史证据：
outputs/run-state.json8705b59ffc40fb221719087d7fb266445cf5bd3f9b58469c3f83291ebd1efefaoutputs/topology-change.json8b75c92a22c753c3bcf4cfe4a2ba62007956f2d610acd776de0160745ad0e06foutputs/gate-overall.json39de2a14aba6a2557676abcff2549e3b58950ef42d90f04f178cb17db52b5948**我们已尝试：**Operator 本地候选补了 drain 尝试持久化、实例核验和不确定状态下保留保护；内核本地候选补了实例绑定的
BeginDrain／QueryDrain。临时源码 workspace 的控制器／envtest／race 和内核定向测试通过。这些是本地候选验证，未部署到发生故障的环境。unit-agent 的交接／取消候选也已分析，但精确cos依赖不可得，本地测试为BLOCKED_ENVIRONMENT。**目前阻塞：**Operator 固定的 MatrixOne 依赖尚无新协议符号，独立构建失败；没有可发布的内核协议版本及旧／新二进制兼容证明，也未完成独立环境的真实双 CN 受控驱逐、部署和 QA。因此不能直接重跑正式 dev campaign。故障的直接触发链已确认，但故障版本究竟在哪一步过早放行锁服务退出，仍需维护方核对 drain 决策。
最近相关改动（截至 2026-09-23）：Operator #617 加固的是远程 pipeline 观测；MatrixOne #28115、#28343、#28474 处理已离开 lock owner 的事务围栏和旧 binding 恢复。它们均在本次 9 月 20 日故障前合入，不能视为已解决本次删除前安全确认。Operator 当前
main仍有 drain 超时放行和does not exist错误放行分支；公开主分支尚未找到本次实例级 drain 修复。旧 run 保留，不以新一次普通 dev 长跑替代受控回归。此 run 的
acceptance_gate=NOT_EVALUATED，不宣称完整产品验收。