Expensify/App中离线创建报告时显示"已删除报告"问题的技术分析

问题背景

在Expensify/App项目中，当用户处于离线状态且工作流功能被禁用时，创建一个新报告会出现异常情况。具体表现为：系统错误地显示"已删除报告"的提示，而实际上用户只是创建了一个空报告。

技术原因分析

经过深入排查，发现问题根源在于报告状态管理逻辑存在缺陷。当工作流功能被禁用时，系统在处理空报告时会错误地将其标记为"已关闭"状态。这一错误状态随后被错误地解读为"已删除"状态，导致用户界面显示不正确的提示信息。

具体来说，问题出在以下几个关键点：

1. 报告状态判断函数getExpenseReportStateAndStatus在处理空报告时，当工作流禁用时会错误返回关闭状态
2. 前端界面基于这个错误状态，触发了"已删除报告"的显示逻辑
3. 后端实际返回的是开放状态报告，与前端乐观数据不一致

解决方案设计

针对这一问题，开发团队提出了两种解决方案思路：

方案一：参数扩展法

在现有状态判断函数中增加isEmptyReport参数，专门用于处理空报告场景。当该参数为true时，跳过关闭状态的错误判断逻辑。这种方案的优势是改动范围小，风险可控。

方案二：专用函数法

为处理空报告创建专门的getEmptyReportStateAndStatus函数，完全独立于常规报告的状态判断逻辑。这种方法逻辑更清晰，但需要更多重构工作。

经过技术评估，团队最终选择了方案一作为实现方案，因为：

1. 改动范围更小，风险更低
2. 能够精准解决当前问题
3. 不会引入额外的维护成本

实现细节

具体实现中，开发团队主要做了以下关键修改：

1. 在状态判断函数中添加isEmptyReport参数
2. 修改状态判断逻辑，当isEmptyReport为true时强制返回开放状态
3. 在创建空报告时正确传递该参数
4. 更新相关测试用例以覆盖这一场景

测试验证

为确保问题得到彻底解决，团队设计了专门的测试用例：

1. 创建一个工作区并禁用工作流功能
2. 进入离线状态
3. 尝试创建新报告
4. 验证报告预览是否正常显示空报告状态

这一测试场景被纳入自动化测试套件，防止未来回归。

经验总结

这一问题的解决过程为我们提供了宝贵的经验：

1. 状态管理逻辑需要特别关注边界条件
2. 离线场景下的数据一致性需要额外验证
3. 乐观数据更新需要与后端逻辑保持同步
4. 功能开关(如工作流禁用)可能引入非预期行为

这类问题提醒我们在设计状态管理系统时，需要考虑各种可能的用户操作路径和环境条件，确保系统在所有场景下都能提供一致的用户体验。

后续优化

基于这一案例，团队计划：

1. 审查其他类似的状态管理逻辑
2. 加强离线场景下的测试覆盖
3. 优化乐观数据更新机制
4. 完善功能开关的集成测试

通过这些措施，可以进一步提升应用的稳定性和用户体验。