事后分析：Tauri 2.0 更新错误导致我们的桌面应用在 10k 用户中宕机 3 小时
Source: Dev.to
2024年10月17日 14:22 UTC，我们对基于 Tauri 2.0 的桌面应用程序进行了一次常规更新，该应用每月活跃用户超过 10 000 人。更新后 12 分钟内，应用启动错误率达到 100 %，用户无法访问核心功能。事件持续了 3 小时 7 分钟，并于 17:29 UTC 完全解决。本文事后报告详细说明了根本原因、我们的响应以及为防止再次发生所采取的措施。
Incident Summary
我们的桌面应用使用 Tauri 2.0 构建（迁移已于 2024 年 9 月完成），为小团队提供离线优先的项目管理工具。10 月 17 日的更新包含了针对 Tauri 核心 IPC 处理程序的补丁，旨在修复 v2.0.1 中的一个轻微内存泄漏。部署后，所有使用 v2.0.2（新版本）的用户在启动时看到空白的白屏，且磁盘上没有生成错误日志。发布后 15 分钟内，用户报告蜂拥而至，充斥我们的支持渠道。
根本原因分析
最初的调试指向 Tauri 更新后的 IPC 序列化逻辑与我们自定义的基于 Rust 的命令处理器之间的不匹配。Tauri 2.0.2 更新在 invoke 函数的负载验证上引入了一个破坏性更改：该更新强制对所有字符串负载使用严格的 UTF‑8 编码，而我们的应用通过 invoke 通道发送 base64 编码的二进制数据，以兼容 v1.x 插件的旧版行为。
当应用尝试发送 base64 负载（在极端情况下会包含非 UTF‑8 的填充字符）时，Tauri 2.0.2 的新验证层在 Rust 后端抛出未捕获的 panic，导致核心进程在 webview 初始化之前崩溃。该 panic 未被我们现有的错误边界捕获，因为 Tauri 2.0 更新将 IPC 处理移至独立线程，错误未向前端错误处理器传播。
我们通过将测试设备回滚至 v2.0.1 确认了此问题，功能随即恢复。检查 Tauri 2.0.2 的发行说明发现该验证更改被标记为“次要补丁”，且没有破坏性更改警告，导致我们的 CI 流水线自动批准了此更新。
事件响应时间线
所有时间均为 UTC：
- 14:22 – 通过我们的 CD 流水线将 Tauri 2.0.2 更新部署到生产环境，触发条件为已合并的补丁 PR。
- 14:34 – 通过 Intercom 收到首位用户报告，启动时出现空白屏幕。
- 14:41 – 工程团队通过 Sentry 警报发现 v2.0.2 构建的崩溃率为 100%。
- 14:47 – 决定回滚到之前的 Tauri 2.0.1 构建，但由于缓存的制品，CD 流水线失败。
- 15:02 – 手动回滚到 v2.0.1 完成，但由于 CDN 缓存，仍有 30% 的用户看到 v2.0.2 的更新提示。
- 15:28 – 清除所有 Tauri 构建制品的 CDN 缓存；更新提示停止。
- 16:15 – 确认所有用户已使用 v2.0.1，崩溃率降至 0%。
- 17:29 – 完全定位根本原因；针对负载序列化的补丁已部署到预发布环境。
经验教训
我们在发布流程中识别出四个关键缺口：
- 缺乏足够的破坏性更改检查 – 我们依赖 Tauri 的语义化版本（v2.0.2 被视为补丁）来表示没有破坏性更改，但此次更新包含了未文档化的验证更改。
- 缺少金丝雀发布 – 更新立即部署到 100 % 的用户，没有先在小范围用户中进行分阶段 rollout。
- 错误传播不完整 – Tauri 2.0 的新线程模型用于 IPC，但我们在错误处理时未考虑到，导致了静默崩溃。
- CDN 缓存管理不当 – 我们的 CDN 将构建产物缓存了 24 小时，延长了用户接触到有缺陷更新的时间。
防范措施
- 分阶段发布 – 现在所有 Tauri 更新首先推送给 5 % 的用户，随后在 1 小时的监控窗口后再全面部署。
- 针对 Tauri 更新的自定义验证 – 预部署检查现在会将 Tauri 发布说明与我们应用的 IPC 使用情况进行比对，标记任何验证或序列化的更改，以便人工审查。
- 改进的错误处理 – Rust 命令处理程序现在捕获 IPC 线程中的 panic，并将错误传播到前端，同时将日志回退记录到本地崩溃报告目录。
- CDN 缓存调优 – 构建产物缓存 10 分钟，并可通过我们的 CD 流水线实现即时清除。
- 自动金丝雀测试 – 预生产测试会启动 10 台虚拟机运行新的 Tauri 构建，验证应用启动，并在部署前执行核心功能检查。
虽然此次事件导致了重大中断，但它凸显了我们桌面发布流程中的关键缺口。自从实施这些更改以来，过去两周内发布相关的事件已减少了 90 %。我们正在与 Tauri 核心团队合作，改进未来补丁发布的破坏性变更文档。