best_practice 工作流在 v0.10.19 中更新已有 container 时崩溃

[07-clottattoos-cyber]

问题概述

这个问题不是自定义工作流，而是官方文档 best_practice（最佳实践）中的示例工作流本身无法跑通。

按照文档 best_practice 中的工作流操作时，如果 host_node/create_resource 的 res_id 指向一个已存在的 container，本地执行器会直接崩溃。

这会导致文档里的两步工作流无法跑通：

1. creat_resource 向已有 container 中加入水
2. PumpTransferProtocol 将液体传输到 container1

版本信息

• Uni-Lab-OS v0.10.19
• tag/main commit: c001f6a1512affb48e9ae5c068e201bda3412679

文档位置

docs/user_guide/best_practice.md
第 7.5 - 7.9 节当前给出的配置是：

• creat_resource

  • class_name: container
  • device_id: workstation
  • parent: workstation
  • res_id: container
  • liquid_type: water
  • liquid_volume: 50

• PumpTransferProtocol

  • from_vessel: water
  • to_vessel: container1

复现步骤

1. 启动 Uni-Lab，并完成 registry 上传。
2. 在 Web UI 中创建实验室，包含：
   • workstation（其 protocol_type 包含 PumpTransferProtocol）
   • virtual_transfer_pump
   • container
   • container1
3. 严格按照 best_practice.md 的说明创建工作流。
4. 运行 creat_resource，参数为：
   • res_id=container
   • liquid_type=water
   • liquid_volume=50

期望行为

作为最佳实践文档中的示例工作流，这个流程应该可以直接跑通：

• 已有的 container 被更新为包含 water
• 然后工作流继续执行 PumpTransferProtocol

实际行为

本地 host executor 在线程中崩溃，还没有执行到 PumpTransferProtocol。

报错堆栈如下：

File "unilabos/ros/nodes/base_device_node.py", line 433, in append_resource
    logger.info(f"更新物料{container_instance.name}的数据{found_resource.state}")
AttributeError: 'RegularContainer' object has no attribute 'state'

怀疑的根因

这看起来像一次不完整的重构 / 回归。

在提交 a79c0a8（fix container volume）中，RegularContainer.state 似乎已经被移除：

• unilabos/resources/container.py 中不再定义 self.state
• load_state() 也改为调用 super().load_state(state)

但是 append_resource 仍然在使用旧接口：

logger.info(f"更新物料{container_instance.name}的数据{found_resource.state}")
found_resource.state.update(container_instance.state)

因此，文档中“create_resource 更新已有 container”这条路径在 v0.10.19 上会直接崩溃。

额外说明

文档下一步里还有一个可能的文档 / 实现不一致：

• 文档写的是 from_vessel: water
• 当前 PumpTransferProtocol 的实现看起来更像是要求传入 vessel/resource id，而不是液体名

不过当前最直接的阻塞问题，还是上面的 create_resource 崩溃。

[07-clottattoos-cyber]

补充一个旧版本（v0.10.18）和云端联调的对照结果，供定位回归范围参考。

我这边单独拷贝了一个 v0.10.18 代码副本，并在隔离工作目录下用同一套 AK/SK 做了云端 + 本地联调测试。结果如下：

1. host_node/create_resource 在 v0.10.18 可以成功执行，不会出现当前 v0.10.19 的 AttributeError: 'RegularContainer' object has no attribute 'state'
2. 日志里可以看到旧版本确实走到了“更新已有 container”的分支，并成功返回：
   • 更新物料container的数据{...}
   • Resource tree add completed, success: True
   • Result for /devices/host_node/create_resource ... success
3. 但后续 workstation/PumpTransferProtocol 仍然失败，不过失败原因已经不是 .state，而是 from_vessel 的资源查询失败

旧版本这次失败的具体表现：

• 下发到本地的 from_vessel 是：{'id': 'container', 'name': 'container', 'uuid': ''}
• 下发到本地的 to_vessel 是：{'id': '/workstation/container1', 'name': 'container1', 'uuid': '...'}
• workstation.execute_protocol() 会先让 host 查询 from_vessel 当前资源状态
• 由于 from_vessel.uuid 为空，host_node._resource_get_callback() 会退回到按 id='container' 调 http_client.resource_get()
• 但云端接口对 id=container 返回的是错误：
  • {"code":22018,"error":{"msg":"can not found target node error"}}
• 而同一个资源用完整路径查询是成功的：
  • id=/workstation/container 可以查到

也就是说，v0.10.18 在这个最佳实践工作流里：

• 第一步 create_resource(res_id=container) 是可以成功的
• 第二步 PumpTransferProtocol 又暴露了另一个问题：from_vessel 没有携带可用的 uuid，且 id 是裸 container，没有被规范化成 /workstation/container，导致云端资源查询失败

另外，旧版这里的错误处理也比较脆弱：

• host_node._resource_get_callback() 直接假设 http_client.resource_get() 返回里一定有 http_req["data"]
• 但接口返回错误对象时并没有 data
• 于是先报 Error retrieving from bridge: 'data'
• 后续 workstation 再 json.loads(response.response) 时又会继续失败

综合这次对照测试，我目前看到的是两个问题：

1. v0.10.19 引入了 RegularContainer.state 相关回归，导致最佳实践工作流在第一步就崩溃
2. 就算回退到 v0.10.18，这条最佳实践工作流在第二步还存在 from_vessel 资源标识/查询链路的问题，特别是在与当前云端接口联调时

如果需要，我也可以继续补更精确的日志片段和对应代码位置。

[07-clottattoos-cyber]

补充一个最新验证结果：我在 隔离的 v0.10.19 环境 中做了最小补丁后，已经可以把官方 best_practice 里的这条工作流从云端完整跑通。这里强调一下，这不是自定义 workflow，而是文档里的最佳实践示例。

本次验证方式：

• 隔离代码副本：最新 0.10.19
• 独立 working_dir，不影响原本地环境
• 云端发起 workflow，本地接单执行

结果：

• host_node/create_resource 成功
• workstation/PumpTransferProtocol 成功
• 本地日志显示 steps_executed: 16
• 最终 QueueProcessor / WebSocketClient 都记录为 success

这次能跑通，核心上修了两类问题：

1. create_resource 更新已有 container 时的 .state 回归

• 当前 RegularContainer 已经迁移到 serialize_state()/load_state() / tracker 体系
• 但 append_resource 仍然直接访问 found_resource.state
• 在 v0.10.19 上会触发：
  • AttributeError: 'RegularContainer' object has no attribute 'state'
• 兼容性修复思路：
  • 优先走 serialize_state()/load_state()
  • 保留对旧式 .state 对象的兼容

2. PumpTransferProtocol 的 from_vessel 资源解析问题

• workflow 下发到本地时，from_vessel 实际是裸 id='container'，没有 uuid
• 旧逻辑会直接走云端 resource_get(id='container')
• 云端接口对这个裸 id 返回：{"code":22018,"error":{"msg":"can not found target node error"}}
• 兼容性修复思路：
  • host_node._resource_get_callback() 先本地解析资源
  • 本地 tracker 找不到时，再回退读取本地 startup_config.json
  • 都失败时才回退云端查询

我本地这轮成功执行时，日志里的关键结果是：

• Result for /devices/workstation/PumpTransferProtocol (...) : success
• Job ... workstation/PumpTransferProtocol completed with status: success
• 协议执行了两轮吸/排液，最后更新了 from_vessel / to_vessel 的资源状态

另外还有一个和主问题正交的现象：

• 启动阶段偶发会在 request_startup_json() 这里因为远端 edge/material/download 超时退出
• 我本地联调用了一个“超时回退本地 startup_config.json”的兜底，主要是为了让联调更稳定
• 这个问题看起来更像网络健壮性问题，未必需要和上面两个 workflow 回归修复绑在同一个 PR 里

如果需要，我可以再整理一个更小的 patch，只保留和 best_practice workflow 直接相关的两处修复。

[07-clottattoos-cyber]

补充一个最新进展：

我在隔离的最新版环境里继续验证了这个问题，并且已经可以把官方文档 best_practice 里的这个示例工作流在“云端下发 + 本地执行”的模式下完整跑通：

• create_resource 成功
• PumpTransferProtocol 成功
• 整个 job 最终 success

这次为了确认可提交范围，我把修复重新收敛后看了一遍，和这个工作流直接相关的核心修复可以压缩为两部分：

1. create_resource 更新已有 RegularContainer 时，不再直接假设对象存在 .state，而是兼容当前资源对象的 serialize_state()/load_state() 机制，同时兼容旧式 .state。
2. host_node 在处理 resource_get 时，优先从本地资源树解析资源；这样像文档工作流里 from_vessel=container 这样的裸 id，不会再因为云端接口无法直接解析而失败。

也就是说，目前看这个 issue 的主修复范围可以聚焦在：

• unilabos/ros/nodes/base_device_node.py
• unilabos/ros/nodes/presets/host_node.py

另外我在本地测试时还额外做过一个“startup_config.json 本地回退”的补丁，用来应对偶发的云端启动配置超时；但这个问题和本 issue 的主路径不是同一个问题，可以单独讨论，不必和本修复绑定在一起。

所以目前的判断是：

• v0.10.19 的回归点已经基本定位清楚
• 官方最佳实践工作流可以通过上述两处核心修复恢复
• 这个修复现在已经具备整理成可提交 patch/PR 的条件