bug: ClickHouse migration 0050 fails on historical Compact scores parts on recommended 26.4

快速结论：这个报错通常发生在自托管 Langfuse 从旧版本升级、且 ClickHouse 中存在历史 Compact 数据分片（part）时，迁移尝试对这些旧分片执行 MATERIALIZE INDEX 却找不到表结构中已存在的列。优先排查 ClickHouse 版本与历史 parts 是否早于后期新增的索引列。

适用环境：自托管 Langfuse 4.28.1 升级至 4.70.1，ClickHouse 26.4.5.143（官方推荐 26.4 系列），ARM64 环境；迁移脚本为 0050_scores_trace_index_granularity。原报告未提供 Python、CUDA、显卡信息。

最快修复方案：Issue 中已验证的方案是：暂停 Langfuse web 与 worker，干净停止 ClickHouse 并做一致性备份，将 ClickHouse 从 26.4.5.143 升级到 26.8.34.13 LTS，先运行 Langfuse 4.70.1 镜像内的 ClickHouse 迁移，再启动 Langfuse 服务；迁移 48–53 全部完成，迁移标记为 53 且无未完成 mutation。

注意事项：26.8.34.13 LTS 超出了 Langfuse 当时文档推荐的 26.4 系列，属于已验证但未被文档覆盖的路径；升级 ClickHouse 前必须备份数据卷，并在迁移前确保没有写入。维护者后续已加入针对 Compact parts 的列物化修复，但需确认所使用的 Langfuse 版本是否包含该修复。不要手动修改迁移标记或伪造迁移状态。

问题场景

用户将自托管 Langfuse 从 4.28.1 升级到 4.70.1，ClickHouse 运行在 26.4.5.143。迁移 0050_scores_trace_index_granularity 需要在 scores 表上物化新的 bloom-filter 索引 idx_project_trace_observation_v2，但数据库中保留了在 session_id、dataset_run_id 等列加入之前写入的历史 Compact parts。迁移过程中重写旧 part 失败，新的 web 容器无法就绪并退出，数据库停留在迁移 50 且处于 dirty 状态，后续迁移被阻塞。

报错原文

Code: 341. DB::Exception: Exception happened during execution of mutation
with an old Compact part. Reason:
Code: 10. DB::Exception: Not found column session_id: in block
id String, project_id String, trace_id Nullable(String),
observation_id Nullable(String), event_ts DateTime64(3), is_deleted UInt8.
(NOT_FOUND_COLUMN_IN_BLOCK) (version 26.4.5.143 (official build))
(query: ALTER TABLE ... MATERIALIZE INDEX idx_v2 SETTINGS mutations_sync=2)

原因分析

可能原因是：历史 Compact part 的列集合早于 session_id 和 dataset_run_id 两列的加入，而 ClickHouse 26.4.5.143 在 0050 迁移中对该 part 执行 MATERIALIZE INDEX 时，旧 Compact part 无法正确提供这些已存在于表 schema 中的列，于是触发 NOT_FOUND_COLUMN_IN_BLOCK。该问题可用合成数据和独立 ClickHouse SQL 复现，不依赖 Langfuse 或 SDK 运行。迁移先物化新索引、再删除旧索引的顺序使失败发生在删除之前，失败 mutation 保持未完成状态，并可能阻塞后续 mutation。该迁移本质是 skip-index 粒度优化，Issue 中未观察到由它导致的行删除。

环境排查

确认 Langfuse 版本：升级前 4.28.1，目标 4.70.1。
确认 ClickHouse 版本：故障环境 26.4.5.143；已验证成功环境 26.8.34.13 LTS。
确认是否保留了在 session_id、dataset_run_id 加入之前写入的 Compact parts，而不是重建表后的全新数据。
确认当前迁移状态与迁移标记（故障后停留在 50，dirty）。
确认是否存在未完成的 mutation。
确认部署架构（Issue 中为 ARM64）以及官方 Langfuse 镜像版本。
Python、CUDA、PyTorch、显卡与节点版本：Issue 未提供，与本问题无直接证据关联。

解决步骤

暂停 Langfuse web 和 worker 服务，停止应用写入。
干净停止 ClickHouse，并对数据卷做一次新的一致性备份。
将现有 ClickHouse 服务从 26.4.5.143 升级到 26.8.34.13 LTS。
在启动应用之前，先运行官方 Langfuse 4.70.1 镜像中打包的 ClickHouse 迁移。
在 4.70.1 上启动 web 与 worker 服务。
不要手动修改迁移标记，也不要对受影响数据执行自定义列物化或强制修复；Issue 中的成功部署未使用这些操作。

验证方法

确认 ClickHouse 迁移 48–53 全部完成，包括原本失败的 0050_scores_trace_index_granularity；确认最终迁移标记为 53 且状态 clean；确认未完成 mutation 数量为零；在应用写入暂停的前提下，对比迁移前后所有既有持久化表的逻辑行数一致；确认两个 Langfuse 服务健康，公开 readiness 端点报告版本为 4.70.1。