Expensify/App中提交费用时无限加载问题的分析与解决

问题背景

在Expensify/App项目的9.1.51-0版本中，用户报告了一个关于费用提交功能的严重问题。当用户尝试将已删除的费用重新提交给其他用户时，界面会出现无限加载的旋转图标(spinner)，导致操作无法完成。这个问题在MacOS的Chrome浏览器和桌面应用中均可复现。

问题现象

用户操作路径如下：

1. 与新用户开始聊天
2. 提交两笔手动费用
3. 打开合并的费用报告
4. 删除报告中的费用(这些费用会被转移到个人费用中)
5. 打开其中一笔被删除的费用
6. 尝试将该费用提交给其他用户
7. 选择最初聊天的用户
8. 点击创建费用

预期结果是费用应该成功提交给目标用户，但实际出现的是提交按钮上的无限加载状态。

技术分析

经过深入分析，发现问题根源在于费用删除和重新提交的流程中存在数据不一致。具体来说：

1. 当费用从报告中删除并转移到个人DM报告时，系统需要记录linkedTrackedExpenseReportAction信息
2. 这个信息包含两个关键字段：actionName和IOUTransactionID
3. 在当前的实现中，删除操作没有正确设置这些字段
4. 当用户尝试重新提交这些费用时，系统无法找到必要的信息，导致流程中断

解决方案

修复方案的核心是在删除报告时，乐观地添加必要的actionName和IOUTransactionID信息。具体修改点位于报告删除的逻辑中：

1. 在删除操作中添加对ONYXKEYS.COLLECTION.REPORT的合并操作
2. 同时更新ONYXKEYS.COLLECTION.REPORT_ACTIONS集合
3. 确保包含actionName: CONST.REPORT.ACTIONS.TYPE.IOU
4. 在originalMessage中添加IOUTransactionID和movedToReportID信息

这种修改确保了即使费用被删除和转移，系统仍然保留重新提交所需的完整上下文信息。

技术实现细节

修复的关键代码变更包括：

1. 在删除操作中添加对子报告的乐观更新
2. 设置正确的父报告ID和聊天报告ID
3. 使用特殊的假策略ID(CONST.POLICY.ID_FAKE)标记转移的费用
4. 创建新的报告动作ID来跟踪费用转移

这些变更保证了数据一致性，使得后续的费用重新提交操作能够正常进行。

影响范围

该问题主要影响以下场景：

1. 从报告中删除费用后尝试重新提交
2. 涉及费用转移的个人DM报告
3. 跨报告的费用操作

修复后，所有相关操作流程都能正常完成，不再出现无限加载的情况。

总结

这个问题的解决展示了在复杂的状态管理系统中保持数据完整性的重要性。通过分析问题根源并针对性地补充缺失的数据字段，我们确保了用户操作的流畅性和系统的稳定性。这也提醒我们在实现删除和转移功能时，需要考虑后续可能的操作路径，确保系统状态始终保持一致。

该修复已随9.1.52-0版本部署到生产环境，经过7天回归测试后确认问题已彻底解决。