Expensify/App 中批量保留费用导致应用崩溃的技术分析

问题背景

在Expensify/App的测试过程中，发现了一个严重的应用崩溃问题。当用户在完成测试驱动后，尝试在报告中对多笔费用执行"保留"操作时，应用会意外崩溃。这个问题在iOS应用、Windows和MacOS的Chrome浏览器以及MacOS桌面端都能复现。

问题复现路径

1. 用户登录新账户并选择管理团队费用
2. 完成初步设置后进入报告模块
3. 执行测试驱动流程
4. 在工作区聊天中提交两笔费用
5. 选择这两笔费用并执行"保留"操作
6. 输入保留原因后返回报告页面时应用崩溃

技术分析

崩溃根源

崩溃发生在SearchUIUtils.ts文件的第395行，当尝试处理交易项数据时。核心问题在于交易项数据结构不完整，缺少必要的字段。

数据结构问题

从日志中可以看到，交易项数据仅包含以下字段：

{
    "canHold": false,
    "canUnhold": true,
    "comment": {
        "hold": "5754874901784688229"
    }
}

而完整的数据结构应该包含更多字段，如交易金额、日期、类别等关键信息。这种不完整的数据结构导致应用在处理时无法正确访问必要的属性，从而引发崩溃。

乐观更新机制的问题

问题的根本原因在于bulkHold操作中的乐观更新机制。该机制假设在快照中的交易数据是完整的，但实际上搜索快照中的交易数据可能不完整。当交易数据在搜索快照中缺失时，系统不应该将其包含在乐观更新中。

解决方案

开发团队采取了以下措施解决这个问题：

1. 紧急回滚：由于问题影响严重且修复需要较长时间，团队首先回滚了引入问题的PR（#62329），该PR实现了新的HOLD按钮功能。

2. 深入修复：在回滚后，开发团队有更多时间深入研究问题本质，计划实现更健壮的解决方案。修复方向包括：

   • 完善数据验证机制，确保处理前数据结构完整
   • 改进乐观更新逻辑，处理数据不完整的情况
   • 增强错误处理，避免因数据问题导致应用崩溃

经验教训

这个案例提供了几个重要的技术经验：

1. 数据完整性验证：在处理关键业务数据时，必须进行严格的数据完整性验证，特别是对于可能来自不同来源的数据。

2. 乐观更新的边界条件：实现乐观更新机制时，必须考虑各种边界条件，包括数据不完整的情况。

3. 回归测试的重要性：新功能的引入可能影响看似不相关的功能区域，全面的回归测试至关重要。

4. 紧急响应流程：对于严重影响用户体验的问题，需要有明确的紧急响应流程，包括快速回滚机制。

总结

Expensify/App中这个批量保留费用导致崩溃的问题展示了在复杂应用中数据一致性和完整性处理的重要性。通过分析崩溃原因，我们不仅解决了眼前的问题，也为系统架构的改进提供了方向。未来在类似功能的开发中，需要更加注重数据验证和错误处理，确保应用在各种边界条件下都能稳定运行。