Conversation
从任何 SCHEMA_VERSION < 54 的旧版本升级到本版本的用户,启动即崩: IllegalStateException: Migration didn't properly handle: ai_providers(...AIProviderEntity). ... Found 比 Expected 多出 userAgent 列 根因:提交 0438562「提供商支持自定义请求头与脚本参数」用 customHeaders + scriptParams 取代 userAgent 时只改了 Entity、 没有写迁移删除列。 userAgent 由迁移 40 添加,该迁移不带 IF NOT EXISTS、无条件执行, 因此凡 SCHEMA_VERSION < 54 的库在升级时都会把这一列加回来,而新版 Entity 不认识它 → Room 表结构校验「表里多出一列」失败 → onUpgrade 抛异常 → App 启动即崩。 影响范围:迁移 40 之后的全部已发布版本(v1.10.0-rc1 起),即 v1.10.0 ~ v1.11.0-rc10 的任意版本升级到本版本都会崩。 注:rc 之间的互相升级不受影响,因为 rc 版本的 Entity 均含 userAgent、 彼此一致,只有本版本改变了列集。全新安装也不受影响(KSP 生成的建表 语句已无该列),所以该问题在发布前未暴露。 修复:新增迁移 54 重建 ai_providers 表移除 userAgent。 minSdk 26 对应用户态 SQLite 3.18,无 ALTER TABLE ... DROP COLUMN, 故按迁移 25/32 的先例重建表。 INSERT ... SELECT 的列清单不含 userAgent,故本迁移对两种源状态都成立 (旧库有该列、全新安装的库没有),重复执行也不报 duplicate column。 已验证: - SQLite 端到端复现崩溃(多余列恰为 userAgent,与线上崩溃日志一致) - 迁移后列集/类型/notNull/主键/索引均与 Room 期望精确一致 - 两条升级路径(有/无 userAgent)收敛到同一列集,业务字段全部保留 - scripts/check_migrations.py 通过 用户数据不会丢失:Room 在 onUpgrade 抛异常时回滚了迁移, user_version 停留在崩溃前的值,未产生半迁移状态。
|
@aaazhouaa is attempting to deploy a commit to the jieapi's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughAgentDatabase advances from schema version 53 to 54. The exported Room schema records the version 54 entities. Migration 54 rebuilds ChangesAgentDatabase version 54
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix · Severity of issue fixed: Medium Merge Risk: ⚪ Minimal · up to The database upgrade removes only the obsolete column and preserves the current provider data structure, with no actionable migration risk identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (2 skipped: 2 unsupported.)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
问题
从任意旧版本升级到本版本的用户,App 启动即崩:
根因
提交
04385620「提供商支持自定义请求头与脚本参数」用customHeaders+scriptParams取代
userAgent时只改了 Entity(AIProviderEntity.kt),没有配套迁移删除该列。userAgent由迁移40_add_provider_user_agent.sql添加,该迁移不带IF NOT EXISTS、无条件执行,因此凡
SCHEMA_VERSION < 54的库在升级时都会把这一列加回来,而新版Entity 不认识它,Room 表结构校验「表里多出一列」失败,
onUpgrade抛异常。影响范围
迁移 40 之后的全部已发布版本,即
v1.10.0-rc1起的任意版本(含v1.10.0、v1.10.1、v1.11.0-rc1~rc10)升级到本版本都会崩。两点需要说明,避免误判:
userAgent、彼此一致,只有本版本改变了列集,所以问题只在这一跳才暴露。
修复
新增迁移 54 重建
ai_providers表移除userAgent,SCHEMA_VERSION53 提升到 54。minSdk 26 对应用户态 SQLite 3.18,无
ALTER TABLE ... DROP COLUMN,故按迁移 25/32 的先例重建表。
INSERT ... SELECT的列清单不含userAgent,因此对两种源状态都成立(旧库有该列、全新安装的库没有),重复执行也不报
duplicate column。
验证
Found恰好多userAgent,与线上崩溃日志逐字段吻合notNull/ 主键 / 索引 / 外键均与 Room 期望一致(不只是列名相同)
userAgent)收敛到同一列集,业务字段全部保留python3 scripts/check_migrations.py通过数据安全
用户的库未损坏,升级后数据不丢。Room 在
onUpgrade抛异常时回滚了迁移,user_version停留在崩溃前的值,未产生半迁移状态。日志佐证:迁移 52 出现 5 次、53 出现 4 次、51 从不出现,说明每次启动都在从同一位置重跑。
附带建议
check_migrations.py目前只校验编号连续、SCHEMA_VERSION一致、已发布迁移未被篡改,不校验迁移结果与 Entity 是否一致,所以本次迁移对账全绿却依然崩溃。
可考虑增加一项校验:比对「迁移执行后的列集」与「KSP 生成的
TableInfo期望列集」,能在 CI 阶段提前拦住这类问题(
AgentDatabase_Impl.kt里已有现成的期望值可用)。Summary by CodeRabbit
Bug Fixes
Chores