并发远程会话：issue #325¶

只读生产环境证据¶

检查日期：2026-09-08。本次调查未对生产环境做任何更改。

SSH 目标：sui-alexandria。Compose 目录：/opt/openbot/remote。
Signal 容器：openbot-remote-remote-api-1，创建于 2026-09-01T10:53:29.873613544Z。
运行中镜像：sha256:7f94a50aee8b89ccf16803c0b9811f6fe19a5d876d14cfeed51deb97e4eee6dd。
运行中的 signal-service.ts SHA-256：b1514f74e6b2ff708c430154b793261a667b5b107c69ee6bd79e6c0fd2356efc。其客户端准入代码在主机已有连接时会拒绝任何不同的会话。其协议解析器没有 multiplex 字段。这确认该镜像不支持 multiplex。
观察到的最近 Worker 版本：bf613b5c-8c44-4c73-8226-1c2651bab5c7，版本号 265，创建于 2026-09-08T09:16:13.382129Z，于 2026-09-08T09:16:14.464933Z 以 100% 部署。这是版本证据，而非端到端兼容性结果。
D1 记录 0018_remote_device_sessions.sql 已于 2026-09-04 12:21:44 应用。该 SELECT 未更改任何数据。请勿再次应用或回滚此迁移。
/opt/openbot 不是 Git checkout。公共 Signal 健康路由无法识别源代码版本。

若要重复这些只读检查，请从此仓库运行：

ssh sui-alexandria 'docker inspect openbot-remote-remote-api-1 --format "{{.Image}} {{.Created}}"'
ssh sui-alexandria 'docker exec openbot-remote-remote-api-1 sha256sum /app/remote/api/src/signal-service.ts'
bunx wrangler deployments list --cwd apps/auth-api --json
bunx wrangler d1 execute openbot-auth --cwd apps/auth-api --remote \
  --command "SELECT name, applied_at FROM d1_migrations WHERE name = '0018_remote_device_sessions.sql'" --json

部署流程——需要单独审批¶

在部署前，请先提交并检查预期源代码。在下面的命令中，将已批准的提交用作 HEAD。先运行所需的 CI 检查。如果目标环境缺少 device-session schema 或 Worker，请在部署 Worker 之前应用兼容的增量 D1 迁移。使用现有的生产 CI 部署流程。不要仅凭日期推断 Worker 的兼容性。

在主机上暂存已批准的源代码，且不要替换其配置或密钥文件：

release_dir="/opt/openbot/releases/$(git rev-parse HEAD)"
ssh sui-alexandria "mkdir -p '$release_dir'"
git archive HEAD | ssh sui-alexandria "tar --exclude='.env*' --exclude='*/.env*' -x -C '$release_dir'"
ssh sui-alexandria "ln -s /opt/openbot/remote/.env.production '$release_dir/remote/.env.production'"
ssh sui-alexandria "ln -s /opt/openbot/runtime '$release_dir/runtime'"
ssh sui-alexandria "ln -s /opt/openbot/node_modules '$release_dir/node_modules'"
ssh sui-alexandria "ln -s /opt/openbot/remote/.env.keys '$release_dir/remote/.env.keys'"

运行时和依赖链接让现有的 Dotenvx 包装器可以运行。Docker 会在镜像内根据已批准的 lockfile 安装 Signal 依赖。

在 sui-alexandria 上，切换到该 release 目录。在构建之前保留运行中的镜像。只运行这些 Signal 命令；remote:update 也会更新 coturn，不适用于此处。

signal_previous_image=$(docker inspect openbot-remote-remote-api-1 --format '{{.Image}}')
docker image tag "$signal_previous_image" openbot-remote-api:before-325
# The release directory is named after the commit. `/health/live` shows it after the start.
source_commit=$(basename "$PWD")
printf '%s\n' "$source_commit" | grep -Eqx '[0-9a-f]{40}' || { echo "Not in a release directory." >&2; exit 1; }
remote/bin/dotenvx run --overload -f remote/.env.production -fk remote/.env.keys -- \
  docker compose -p openbot-remote -f remote/compose.yaml build --build-arg "OPENBOT_SOURCE_COMMIT=$source_commit" remote-api
remote/bin/dotenvx run --overload -f remote/.env.production -fk remote/.env.keys -- \
  docker compose -p openbot-remote -f remote/compose.yaml up -d --no-build --no-deps remote-api
docker inspect openbot-remote-remote-api-1 --format '{{.Image}} {{.State.Health.Status}}'
curl --fail --silent --show-error https://signal.openbot.run/health/ready
curl --fail --silent --show-error https://signal.openbot.run/health/live

/health/live 必须显示 release 提交。在该字段存在之前构建的版本不显示 commit；未使用 OPENBOT_SOURCE_COMMIT 构建的版本显示 unknown。

等待 Docker 健康检查状态变为 healthy。检查运行中的源代码是否包含 multiplex，并记录其校验和。在下面的设备检查通过之前，保留之前的镜像。不要打印容器环境变量、恢复令牌（resume tokens）、票据（tickets）或原始连接日志。

Signal 替换会关闭信令 WebSocket。在信令重新连接期间，现有 WebRTC 数据通道应继续保持。重启后的第一次恢复会检查持久化控制平面。当账户服务无响应时，Signal 会以 1013 关闭 socket，且不发送错误帧；对端在退避后再次连接，会话不会结束。Coturn 保持运行，因此该更新不会刻意终止其中继分配。请用活动连接验证这一点；仅靠健康检查无法证明。

如果新的 Signal 失败，请从同一 release 目录恢复保留的镜像：

docker image tag openbot-remote-api:before-325 openbot-remote-remote-api
remote/bin/dotenvx run --overload -f remote/.env.production -fk remote/.env.keys -- \
  docker compose -p openbot-remote -f remote/compose.yaml up -d --no-build --no-deps --force-recreate remote-api

回滚会恢复旧的单会话限制。它不会回滚 D1 迁移，也不会撤销设备会话。

必做设备验证——待完成¶

使用当前桌面端 B 作为主机，桌面端 A 作为客户端，并搭配一个来自兼容来源的移动客户端。记录它们的版本、Worker 版本、D1 迁移结果以及 Signal 镜像。

将移动端连接到 A，在移动端接受 B 的 Member 邀请，然后在 A 上打开 B。
在移动端打开 B 之前，让 A 先加入 B，重复此操作。两个客户端都必须加载 B 的 agent 和数据。
停止 A。移动端必须保持与 B 的连接。并以一个设备会话断开的情况重复上述操作。
重新连接 A，并验证其 agent 列表和数据能够刷新。在加载尚未完成时切换服务器；旧的响应不得替换所选服务器的数据。
使用一个未包含 multiplex 的旧主机，连接第二个客户端。它必须显示连接错误并提供 Retry，同时第一个客户端保持连接。在成功之前，Retry 必须一直保留该错误。
在已批准的 Signal 替换过程中，检查活动数据通道是否仍然存活，并且两个客户端能否恢复信令。同时测试中继连接和直连。

在这些检查通过之前，不要关闭 issue #325。PR #324 仍然分开；其邀请 UI 改动不包含在此。未添加自动 Signal 部署。

本页原文 Markdown：在 AtomGit 查看·内容源自开源项目 openbo/openbot