Expensify/App 中提交费用后显示加载器而非预览的问题分析

问题描述

在 Expensify/App 的 9.1.51-0 版本中，用户提交费用后遇到了一个显示异常问题。当用户完成费用提交操作后，界面本应显示费用预览，但实际上却显示了一个大型加载器（loader），导致用户无法立即查看提交的费用详情。

问题重现

这个问题在两种场景下可以重现：

1. 直接消息场景：

   • 用户登录 Gmail 账户
   • 进入直接消息界面
   • 向其他用户提交两笔费用
   • 点击费用预览时出现加载器

2. 自我对话场景：

   • 使用支持自我对话的账户
   • 进入自我对话界面
   • 记录手动费用时
   • 同样出现加载器而非预览

技术背景

这个问题属于前端显示逻辑的异常。在正常的应用流程中，当用户完成费用提交后，前端应该立即获取并渲染费用详情，显示预览界面。而出现加载器表明系统仍在等待某些数据或操作完成，未能及时进入预览状态。

问题原因

根据开发团队的快速响应，这个问题是由一个特定的 Pull Request (#61854) 引入的。该 PR 可能修改了费用提交后的状态管理逻辑，导致前端在应该显示预览时错误地保持了加载状态。

解决方案

开发团队采取了以下措施：

1. 快速回滚：首先回滚了引入问题的 PR (#61854)，这是处理生产环境问题的标准应急措施。
2. 后续修复：随后提交了专门的修复 PR (#62767) 来解决这个问题。

影响范围

这个问题影响了多个平台：

• Android 应用和移动网页版
• iOS 应用和移动网页版
• Windows 和 MacOS 的桌面版及网页版

技术启示

这个案例展示了几个重要的开发实践：

1. 回归测试的重要性：虽然问题在生产环境才被发现，但完善的测试流程可以帮助提前发现这类显示逻辑问题。
2. 快速响应机制：团队建立了有效的应急响应流程，能够快速定位问题源头并采取补救措施。
3. 状态管理复杂性：前端状态管理（特别是涉及异步操作时）容易出现问题，需要特别注意状态转换的正确性。

总结

Expensify/App 团队通过快速识别问题源头并采取有效措施，成功解决了这个影响用户体验的界面显示问题。这个案例也提醒开发者在修改涉及状态转换的代码时需要格外谨慎，并确保有充分的测试覆盖。