Expensify/App 中部分审批失败的API错误分析

前言

在Expensify/App项目的日常使用中，审批流程是一个核心功能。最近发现了一个关于部分审批时出现的异常情况：当审批链中的第一个审批者尝试部分批准包含保留费用的报告时，系统会出现"意外错误"提示，同时整个报告被意外完全批准而非部分批准。本文将深入分析这一问题的技术背景和解决方案。

问题现象

在标准的审批工作流中(员工提交→审批者1→审批者2)，当员工提交包含多个费用的报告并保留其中部分费用时，审批者1尝试部分批准未保留的费用时会出现以下异常：

1. 系统显示"意外错误，请稍后再试"的错误提示
2. 整个报告被完全批准，而非预期的部分批准
3. 报告被直接转发给审批者2，而非保持部分批准状态

技术背景分析

Expensify的审批系统采用多级审批链设计，支持部分批准和费用保留功能。当审批者执行部分批准操作时，系统需要：

1. 批准选中的费用
2. 处理未被批准的费用(保留或转发)
3. 更新报告状态
4. 触发后续审批流程

根本原因

经过代码分析，发现问题出在approveMoneyRequest函数的处理逻辑上：

1. 当前实现会在任何部分批准操作时创建保留数据，无论当前审批者是否为审批链中的最后一个审批者
2. 当非最终审批者发送保留数据时，后端API会拒绝该请求
3. 这种拒绝导致前端错误提示，同时触发了整个报告的完全批准作为回退机制

解决方案

修正方案需要修改approveMoneyRequest函数的处理逻辑：

1. 引入isLastApprover(approvalChain)辅助函数，判断当前用户是否为审批链中的最后一个审批者
2. 仅当用户是最终审批者时，才执行保留报告的创建逻辑
3. 对于中间审批者，跳过保留报告创建步骤，仅处理部分批准逻辑

测试场景建议

为确保修复的可靠性，建议覆盖以下测试场景：

1. 非最终审批者的部分批准操作

   • 验证报告保持部分批准状态
   • 确认无API错误发生
   • 检查未创建新的保留报告

2. 最终审批者的部分批准操作

   • 验证保留报告被正确创建
   • 确认剩余保留费用移动到保留报告中

3. 完整批准操作

   • 验证报告被完全批准
   • 检查所有保留被正确清除

4. 混合顺序的重复批准

   • 验证无意外错误发生
   • 确认报告状态更新正确

架构思考

这个问题反映了工作流系统中状态管理的重要性。在多级审批场景中，每个审批者的操作权限和影响范围需要明确定义。部分批准作为一种特殊操作，其行为应根据审批者在链中的位置而有所不同：

• 中间审批者：仅能批准/拒绝，不能创建长期保留
• 最终审批者：拥有完整权限，包括创建保留报告

这种分层权限设计既保证了工作流的灵活性，又避免了状态管理的混乱。

总结

Expensify/App中的这个审批流程问题展示了复杂工作流系统中边界条件处理的重要性。通过明确区分中间审批者和最终审批者的权限，可以构建更健壮的审批系统。这种解决方案不仅修复了当前问题，也为未来可能的工作流扩展奠定了良好的基础。