Expensify/App移动端费用报告功能崩溃问题分析

问题背景

在Expensify移动应用的最新版本中，测试人员发现了一个严重的功能性问题。当用户尝试将费用从个人聊天转移到工作区报告时，应用会出现崩溃现象。该问题主要影响Android平台的折叠屏设备，特别是在快速操作场景下。

问题现象

用户在完成以下操作流程时会遇到应用崩溃：

1. 创建工作区并进入工作区聊天
2. 提交一笔费用
3. 点击费用预览
4. 选择报告功能
5. 从报告中移除该费用
6. 进入个人聊天
7. 再次点击费用预览
8. 快速选择报告功能
9. 选择之前创建的工作区报告

技术分析

经过深入排查，发现问题根源在于后端API返回的数据格式与前端预期不符。具体表现为：

1. 数据不一致性：当用户快速操作时，后端GetMissingOnyxMessages API返回的交易记录中reportID字段为空字符串，而非预期的有效报告ID或null值。

2. 前端处理不足：前端代码在IOURequestStepReport组件中直接使用了这个可能为空的reportID来构建Onyx存储键值，没有进行充分的空值处理。

3. 状态更新延迟：快速操作导致交易记录的reportID更新存在延迟，而前端已经尝试基于这个尚未更新的值进行后续操作。

解决方案

针对这个问题，开发团队提出了多层次的解决方案：

1. 后端修复：修正API返回的数据格式，确保reportID字段始终返回有效值或null，避免空字符串的情况。

2. 前端容错处理：在IOURequestStepReport组件中添加防御性编程，当reportID无效时使用undefined作为回退值，并设置canBeMissing标志为true。

3. 状态同步优化：考虑在前端添加状态检查机制，确保在reportID更新完成后再进行相关操作。

经验总结

这个案例为我们提供了几个重要的开发经验：

1. API契约稳定性：前后端接口必须保持严格的数据格式约定，特别是对于可能为空的字段。

2. 用户操作容错：对于用户可能的快速连续操作场景，应用需要具备足够的鲁棒性。

3. 折叠屏设备适配：新型设备的特殊交互方式可能暴露出传统测试中难以发现的问题。

4. 防御性编程：关键数据路径上必须添加充分的错误处理和边界条件检查。

通过这次问题的分析和解决，Expensify应用在费用报告功能的稳定性和用户体验方面得到了显著提升。