Chroma 报 collections.topic 不存在，先查哪个旧客户端还在访问库

打开持久化 Chroma 或查询集合时出现：

sqlite3.OperationalError: no such column: collections.topic

官方 issue #2837记录了 0.4/0.5 混用后的问题。贡献者要求确认实际访问库的客户端版本，而不只是确认某个终端执行过升级。这是历史 schema 迁移场景，不能把所有新版 SQLite 错误都归到这一列。

在 Chroma 0.5.7 的迁移文件里，可以看到移除 topic 的 SQL。旧代码继续请求旧列，就会失败。给新库手工加回一列，不能恢复整套旧版数据契约。

每个读写入口分别查版本

在 Web 服务、worker、Notebook 和维护脚本各自的实际解释器中执行：

python -c 'import sys,chromadb; print(sys.executable); print(chromadb.__version__); print(chromadb.__file__)'
python -m pip show chromadb chromadb-client

容器还要记录正在运行的镜像与启动配置。修改 requirements 并不证明原容器已经换版本；重启 Notebook 页面也不等于重启内核。

同时核对各入口连接的服务地址、持久化目录、tenant/database 和 collection。升级后出现“集合不存在”或空结果，也可能是读到了另一目录；不要为了消除错误用 get_or_create_collection 创建一份同名空库来冒充恢复。

先保留数据，再统一兼容组合

迁移会写系统数据库。停止相关写入，按部署方式取得一致备份；本地嵌入式部署保留完整持久化目录，不仅复制单独一个 SQLite 文件，远程部署采用对应服务的备份方法。确认备份能在隔离环境恢复后再改版本。

对于已经迁至历史 0.5.x schema 的库，应让访问者使用对应兼容版本。Chroma FAQ说明，这次自动迁移不能通过重新安装旧包逆转。当前大版本的升级链应另外核对，不拿历史 0.5.x 当今天的统一推荐。

先在数据副本中让兼容客户端列出原集合，再核对已知集合计数、文档 ID 和代表性查询。用正常 get_collection 读取已有对象；恢复过程中不调用 reset，也不删除集合。

如果必须退回迁移前软件，应同时恢复迁移前数据快照。保留新库和备份，不让旧客户端反复打开新 schema。

验收应覆盖每个实际读写者：新进程启动后访问相同数据目标，不再报列缺失，原集合和抽样记录仍在，检索结果符合旧测试集。只有一个命令行脚本成功，不能排除线上 worker 仍在运行旧版本。