codex-app-server

431 Commits 3 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
muse	c1cb3f3d82	CI: tolerate runner mtime lag and stream heartbeat race in 2 browser tests (test-only, no production code change; playwright: 0.05s sleep after write_control, runner mtime lags wall clock 0.2-1.0ms; stream: drain waiting heartbeats until EOF after terminal status) ci / test (push) Failing after 16m9s Details	2026-11-04 17:11:23 +01:00
host	910168126d	perf: 桥变化才写、stdin 优先、stream 50ms 轮询 1. 桥写放大：旧代码每 ~50ms 轮询都无条件重写 state 和帧文件（约 40 次原子 temp+replace/s 走 runsc gofer，泵持久返回同一帧、updated_at 每轮都变，字节其实不变）。现帧字节不变不写；state 只在 url/title/started/holder/ streaming 变化时写，或 0.5s 心跳一次（判死阈值 30s，绰绰有余）；静态页写量从 ~40次/s 降到 ~2次/s。 2. MCP 主循环 stdin 优先：旧循环先 drain 再读 stdin，每次工具调用都先付一轮文件 IO。现 pending 请求先处理，空闲轮询 drain，忙时 200ms 保底 drain 一次防饿死。 3. stream 轮询 200ms → 50ms，画面延迟下限随之下降。附回归测试：无变化轮询不重写、帧变化立即写、holder 变化绕过节流立即写。	2026-10-30 13:36:24 +08:00
host	6bcdeb8da1	fix: 浏览器远控传输层改文件桥（Unix socket 在 runsc 下宿主不可见）根因（2026-10-30 活体实证）：#181 的 .browser-remote.sock 假设宿主能连容器内 socket，但生产 Docker 任务走 runsc/gVisor，其 gofer 挂载下容器内建的 socket 只在容器内可见，宿主目录里只有普通文件（browser-live.png 一直能透传）。后果：server 代理对真实任务一律 503，会话根本没活过。修法：传输层改四个普通文件（worktree 内，原子写 + 追加日志）： - .browser-remote-state.json：MCP 每轮重写，mtime 即存活信号， server 判 30 秒无心跳为会话死亡（503）； - .browser-remote-frame.jpg：最新 screencast 帧（base64 文本）； - .browser-remote-input.jsonl：server 追加，MCP 按偏移量消费完整行，执行时再判 holder，半行等下一轮； - .browser-remote-control.json：{holder, seq}，MCP 首轮即应用，接管可先于浏览器启动。 - holder 竞态：control 写下后 state 文件约 50ms 才刷新，server 的 input/stream 改判 effective_holder（控制文件 mtime 新者胜），否则接管后立刻点会误 409。 - 线程契约与控制权模型不变；MCP 主循环仍是唯一触页线程。 - 播种刷新（#181）让老租户自动拿到新版脚本。测试：socket 测试改文件桥测试（桥轮询/偏移量/半行/陈旧态/ effective_holder + server 代理全链），全量 1357 项通过（skipped 4）。	2026-10-30 07:28:32 +08:00

Author

SHA1

Message

Date

muse

c1cb3f3d82

CI: tolerate runner mtime lag and stream heartbeat race in 2 browser tests (test-only, no production code change; playwright: 0.05s sleep after write_control, runner mtime lags wall clock 0.2-1.0ms; stream: drain waiting heartbeats until EOF after terminal status)

ci / test (push) Failing after 16m9s

Details

2026-11-04 17:11:23 +01:00

host

910168126d

perf: 桥变化才写、stdin 优先、stream 50ms 轮询

1. 桥写放大：旧代码每 ~50ms 轮询都无条件重写 state 和帧
   文件（约 40 次原子 temp+replace/s 走 runsc gofer，
   泵持久返回同一帧、updated_at 每轮都变，字节其实不变）。
   现帧字节不变不写；state 只在 url/title/started/holder/
   streaming 变化时写，或 0.5s 心跳一次（判死阈值 30s，
   绰绰有余）；静态页写量从 ~40次/s 降到 ~2次/s。
2. MCP 主循环 stdin 优先：旧循环先 drain 再读 stdin，
   每次工具调用都先付一轮文件 IO。现 pending 请求先处理，
   空闲轮询 drain，忙时 200ms 保底 drain 一次防饿死。
3. stream 轮询 200ms → 50ms，画面延迟下限随之下降。
附回归测试：无变化轮询不重写、帧变化立即写、holder
变化绕过节流立即写。

2026-10-30 13:36:24 +08:00

host

6bcdeb8da1

fix: 浏览器远控传输层改文件桥（Unix socket 在 runsc 下宿主不可见）

根因（2026-10-30 活体实证）：#181 的 .browser-remote.sock 假设
宿主能连容器内 socket，但生产 Docker 任务走 runsc/gVisor，
其 gofer 挂载下容器内建的 socket 只在容器内可见，宿主目录
里只有普通文件（browser-live.png 一直能透传）。后果：server
代理对真实任务一律 503，会话根本没活过。

修法：传输层改四个普通文件（worktree 内，原子写 + 追加日志）：
- .browser-remote-state.json：MCP 每轮重写，mtime 即存活信号，
  server 判 30 秒无心跳为会话死亡（503）；
- .browser-remote-frame.jpg：最新 screencast 帧（base64 文本）；
- .browser-remote-input.jsonl：server 追加，MCP 按偏移量消费
  完整行，执行时再判 holder，半行等下一轮；
- .browser-remote-control.json：{holder, seq}，MCP 首轮即应用，
  接管可先于浏览器启动。
- holder 竞态：control 写下后 state 文件约 50ms 才刷新，server
  的 input/stream 改判 effective_holder（控制文件 mtime 新者胜），
  否则接管后立刻点会误 409。
- 线程契约与控制权模型不变；MCP 主循环仍是唯一触页线程。
- 播种刷新（#181）让老租户自动拿到新版脚本。

测试：socket 测试改文件桥测试（桥轮询/偏移量/半行/陈旧态/
effective_holder + server 代理全链），全量 1357 项通过（skipped 4）。

2026-10-30 07:28:32 +08:00