Multiuser: CLI user changes (invoke-usermod/userdel) don’t revoke live socket connections

快速结论：该问题发生在 InvokeAI 多用户模式下，通过 CLI 工具（invoke-usermod / invoke-userdel）在服务器外部修改用户权限时，已建立的 Socket.IO 连接不会立即失效。该问题已在 PR #9360（合并于 2026-08-18）中修复，核心方案是增加周期性的连接用户复核（reconciliation sweep）机制。

适用环境：InvokeAI（main 分支，包含 PR #9360 的版本）；多用户模式；SQLite 数据库。Issue 中未确认具体操作系统、Python、CUDA 或显卡版本，不做补充。

最快修复方案：升级到包含 PR #9360（commit 2ea518a532）的版本。该版本已实现周期性复核机制：SocketIO._revalidate_socket_users 每 30 秒（SOCKET_REVALIDATION_INTERVAL_SECONDS = 30.0）重新从数据库派生房间成员关系，对已删除或停用的用户断开其所有 socket 连接，并根据角色变化调整 admin 房间。

注意事项：修复版本中，数据库持续读取失败 3 次（SOCKET_REVALIDATION_FAILURE_LIMIT）后仅撤销 admin 权限，不主动断开连接，以避免数据库故障时误杀所有在线会话。若需要限制此场景下的 stale admin 访问时长，需单独提 Issue 讨论，原 Issue 已关闭不再处理。

问题场景

在 InvokeAI 多用户模式下运行服务器，用户通过浏览器保持登录状态（socket 已连接）。管理员在服务器 shell 中执行 invoke-userdel 删除用户，或通过其他外部方式修改用户权限后，被操作的用户仍然保持 socket 连接、继续接收事件（包括 admin 房间事件），直到手动刷新页面才会断开。

报错原文

Multiuser: CLI user changes (invoke-usermod/userdel) don't revoke live socket connections

原因分析

根据 Issue 讨论，根因是 Socket.IO 的房间成员关系仅在连接建立时根据当时的用户记录决定一次，之后只通过服务器内部的 user_access_changed 事件来更新。CLI 工具（invoke-usermod / invoke-userdel）是独立进程，直接操作 SQLite 数据库，无法访问运行中服务器的事件总线，因此无法触发该事件。这导致 REST 请求（每次重新读取数据库）能立即感知权限变化，而 socket 连接不能。

环境排查

确认 InvokeAI 版本是否包含 PR #9360（合并 commit 2ea518a532）；修复前版本存在此问题
确认是否运行在多用户模式
确认数据库为 SQLite（config.db_path）
如使用直接 sqlite3 编辑用户表，需确认复核机制已随旧版升级生效

解决步骤

升级 InvokeAI 至包含 PR #9360 的 main 分支版本（合并于 2026-08-18）
升级后无需额外配置，复核机制自动随应用生命周期启动（socket_io.start() / socket_io.stop()）
CLI 工具在权限变更后会提示：“A running server applies this to new requests immediately; already-open connections are re-checked within about a minute.”
若需立即生效而非等待最多 60 秒，可通过 API 执行停用操作（API 同步发出 user_access_changed 事件），或接受复核机制的短暂延迟
注意：invoke-usermod 没有停用（deactivate）参数，仅支持 --name、--password、--admin、--no-admin 选项

验证方法

升级后执行 invoke-usermod --no-admin 或 invoke-userdel，观察被操作用户的 socket 是否在约 30-60 秒内断开，且不再收到对应权限范围的事件。官方验证显示 97 个相关测试全部通过，覆盖 TestRevalidationSweep 和 TestRunningQueueOwnersAreSwept 场景。