[错误]: PhysicalMachineChaos: 自动恢复在空 UID (404) 条件下失败,攻击持续运行

可复现的错误描述 ChaosMesh 版本 v2.8.3 Kubernetes 版本 v1.33.10 当一个 PhysicalMachineChaos 实验的持续时间到期时，控制器-管理器尝试通过向 chaosd 发送一个 DELETE 请求来自动恢复，但该请求中使用的 uid 为空，导致 404 错误，并且攻击在目标上无限期地运行。 在创建时，chaosd 在 200 OK 响应体中返回了一个有效的 uid（例如，{"status":200,"message":"attack successfully","uid":""）。但是，此 uid 似乎没有被保存，控制器的 Recover() 调用无法从中读取它 - 重新调整器内部使用的通用 Record.id 字段设置为目标地址（https://:port），而不是由 chaosd 生成的 uid。 通过 GET /api/experiments/ 方法获得的 uid 手动调用 DELETE /api/attack/{uid} 直接对 chaosd 进行请求，这正确地清除了攻击（内存被释放/文件被删除，状态转移到被销毁），这证明了正确的恢复端点以及 chaosd 本身在提供正确的 uid 时的正确行为。 我们还尝试在 PhysicalMachineChaos YAML 中明确设置 spec.uid（如 #4622 中使用的网络丢失），希望控制器将其转发到创建负载中并重新使用它进行恢复。 这没有任何效果 - 发送给 chaosd 的压力/磁盘创建负载中从来不包含 uid 字段，无论 spec.uid 设置为何种值。 ### 可复现的步骤 1. 在可通过 mTLS 从集群访问的目标 VM 上部署 chaosd 以服务模式。 2. 使用以下命令应用一个 PhysicalMachineChaos 实验，持续时间短，例如： kind: PhysicalMachineChaos apiVersion: chaos-mesh.org/v1alpha1 metadata: namespace: name: test-vm-mem-repro spec: action: stress-mem address: - https://:31768 selector: {} mode: all stress-mem: size: 250MB duration: 2m 3. 观察控制器-管理器日志：创建调用成功并记录了一个 uid。 4. 等待持续时间到期。 5. 观察控制器-管理器日志：记录了恢复物理机 chaos，然后是实验未找到 {"uid": ""} 和来自 chaosd 的 404 错误。 6. 确认攻击仍然在目标上运行（例如，内存使用率保持高水平/磁盘填充文件仍然存在）。 7. 手动运行 DELETE /api/attack/{uid} 请求对 chaosd（通过 GET /api/experiments/ 方法获得的 uid） - 这成功并正确地停止了攻击，这证实了 chaosd 的 API 在提供正确的 uid 时按照预期工作。