flvx/.entire/metadata/ses_34ec18cadffeoVVSjfPXGJaxBu/context.md

Session Context

Session ID: ses_34ec18cadffeoVVSjfPXGJaxBu Commit Message: 再做一轮“跨表全量列对比（model vs 旧库补列逻辑）

Prompts

Prompt 1

211任务全量再逐一确认一下是否全部完成，并且功能完成

Prompt 2

添加额外ip的时候报错：SQL logic error: no such column: extra_ips (1)

Prompt 3

全量排查一下还有没有类似的bug

Prompt 4

再做一轮“跨表全量列对比（model vs 旧库补列逻辑）

Summary

已完成这一轮“跨表全量列对比（model vs 旧库补列逻辑）”，并做了可执行验证。

我做了什么：

• 对比了 model.Node / model.Tunnel 字段与 prepareSQLiteLegacyColumns 的补列清单。
• 结论：
  • Node 目前应补的历史增量列：server_ip_v4, server_ip_v6, extra_ips, tcp_listen_addr, udp_listen_addr, inx, is_remote, remote_url, remote_token, remote_config
  • Tunnel 应补：inx, ip_preference
• 我已把这个对齐结果固化为回归测试，新增了一个“更老版本库”场景验证：
  • 新测试：TestOpenMigratesVeryLegacyNodeAndTunnelColumns
  • 文件：go-backend/tests/contract/migration_contract_test.go
  • 该测试从极简旧表结构启动，验证上述所有列都会被自动补齐。
• 测试结果：通过
  • go test ./tests/contract -run "TestOpenMigratesLegacyNodeDualStackColumns|TestOpenMigratesVeryLegacyNodeAndTunnelColumns"

最终结论（本轮排查范围内）：

• Node/Tunnel 这条旧库升级链路已对齐且有测试兜底。
• 你这类 “no such column” 的同类风险，针对这两个核心表已经基本封住。