Skip to content

feat(ostool-server): rebuild admin UI with realtime updates and unbound power control - #183

Merged
ZR233 merged 5 commits into
mainfrom
codex/admin-react-events
Sep 10, 2026
Merged

feat(ostool-server): rebuild admin UI with realtime updates and unbound power control#183
ZR233 merged 5 commits into
mainfrom
codex/admin-react-events

Conversation

@ZR233

@ZR233 ZR233 commented Sep 10, 2026

Copy link
Copy Markdown
Member

新建开发板时,设备可能尚未上电,原界面无法在绑定 MAC 前控制电源。本次增加独立电源动作接口,并将管理界面迁移到 React + TypeScript + shadcn/ui,通过 SSE 原位更新状态。

主要改动

  • 支持未保存板卡、没有 MAC 或会话时手动上电/下电;复用 Custom、继电器和 QEMU 执行器,提供请求幂等、资源互斥、异步结果和恢复查询。
  • 增加统一管理状态投影及 SSE 快照、epoch/revision 游标和有界重放;覆盖 Loader 到期、进程退出与系统设备变化。前端共享一个连接,断线保留内容,编辑草稿与推送状态分离。
  • 完整迁移总览、开发板、DTB、会话租约、TFTP 和 Server 配置;压缩开发板过滤器,优化分组表单及窄屏布局,将启动架构收进高级设置。保留 /admin/ 路由、MAC 预填及现有 CLI/axloader/串口协议。
  • 启动时将不兼容的板卡配置移动至 quarantine,保留原文件及 reason.json,并在界面提示;有效板卡继续加载。
  • 更新中英文文档、前端嵌入构建及 CI,移除 Vue/Pinia 依赖并加入前端单元和浏览器测试。

验证

  • 缺陷回归先失败后通过:未绑定电源动作、无效配置隔离。
  • Rust:133 个服务器单元测试、3 个串口生命周期集成测试;workspace fmt/clippy/build/test 和 publish dry-run 通过。
  • 前端:16 个单元测试、生产构建、2 个真实服务器 Playwright 集成测试通过,覆盖六个模块、上电发现绑定、断线恢复、跨客户端草稿以及无周期性页面数据请求。
  • 在隔离网络命名空间中完成真实 QEMU/axloader 上电、发现、绑定及下电链路验证;桌面与窄屏页面已检查。
  • 已在授权目标环境完成部署验证:17 块板卡正常加载,六个页面与 SSE 正常,新客户端会话成功分配。切换前等待已有会话结束,保留旧程序和配置备份。

验证边界

QEMU/axloader 联调与已部署服务检查不能替代每一种实体板及继电器的实机验收。实体板无电源反馈时,界面只表示命令完成,不宣称确认物理上电。

@ZR233
ZR233 merged commit bb7645e into main Sep 10, 2026
2 checks passed
@ZR233
ZR233 deleted the codex/admin-react-events branch September 10, 2026 08:05
@github-actions github-actions Bot mentioned this pull request Sep 10, 2026

@mai-team-app mai-team-app Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

审查结论

本 PR 引入了管理端 revisioned SSE 投影和 OS 事件监视器,新增电源操作 API,并将 Web UI 重写为 React/Vite,同时整合 loader、虚拟设备、board/session 状态和文档。这些改动会影响管理端事件流、网络/串口/TFTP 状态刷新、session 生命周期以及前端 API 契约,因而并非完全孤立的 UI 变更。

阻塞问题

我发现 1 个阻塞问题,已作为右侧行内评论提交:Linux netlink 监视器用空 buffer 调用 datagram socket 的 recv,收到首个网络事件后不会消费队列,可能让 readiness 永远保持就绪并造成高 CPU 忙循环。

验证与背景

  • GitHub Actions 的两个 check run 均为 completed/success,且目标 head 仍为 b6b9f3c5f83b61b8fbafacf1513a13224e7c9292
  • 本地 git diff --check 通过;但审查环境没有 cargorustcpnpm,因此无法独立运行 Rust 格式化、clippy、测试或 Web UI 构建。PR 描述中列出的验证结果未能在本地复现。
  • 已检查既有 reviews、review comments 和 issue comments,当前没有此前的可执行审查意见需要处理。
  • 已检索 admin/eventsloader/networkwebui/admin 相关历史 PR,未发现需要在本次审查中合并处理的直接重复方案。

除上述问题外,当前没有确认的其他阻塞问题;修复 netlink 接收循环后仍建议在 Linux 环境补跑完整 Rust/Web UI 验证。

Powered by gpt-5.6-luna

let Ok(mut ready) = socket.readable().await else {
break;
};
let result = ready.try_io(|fd| fd.get_ref().recv(&mut Vec::<u8>::new(), 0));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这里把空 Vec<u8> 传给了 netlink datagram socket 的 recv。对这种 socket,零长度接收会返回 0 但不会消费队列中的消息;因此第一次 link/address 事件后,readable() 可能一直保持 ready,任务会在紧循环中反复 invalidate(["network"]) 并占满 CPU。请改用实际的有界 buffer,并在重新等待 readiness 前循环接收直到 WouldBlock

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant