Expensify/App 移动费用功能中已删除工作区报告的显示问题分析
2025-06-15 02:22:47作者:郁楠烈Hubert
在Expensify/App项目的费用管理模块中,开发团队发现了一个关于移动费用功能的边界条件问题。当用户尝试将费用移动到其他报告时,系统错误地显示了已被删除工作区中的费用报告选项。
问题背景
该问题出现在费用管理流程中的"移动费用"操作环节。正常情况下,用户应该只能看到当前活跃工作区中的费用报告列表。然而,在某些特定操作序列下,系统会错误地包含已被删除工作区中的报告选项。
问题复现步骤
- 创建一个新工作区
- 在工作区聊天中提交一个费用
- 删除该工作区
- 创建另一个新工作区
- 在新工作区中提交另一个费用
- 尝试移动这个新费用时,已删除工作区的报告会出现在可选列表中
技术原因分析
问题的根本原因在于报告筛选逻辑中存在缺陷。具体来说,isReportOutstanding函数没有正确处理已归档报告的状态检查。该函数负责确定哪些报告应该出现在可移动目标的列表中,但未能正确识别和过滤掉已归档(即被删除工作区关联的)报告。
在代码实现层面,getOutstandingReportsForUser函数返回的结果包含了不应该出现的已归档报告。这源于之前的一个PR修改(#62270)引入的筛选条件不完整问题。
解决方案
开发团队采用了双重保障的修复策略:
- 在
isReportOutstanding函数中显式添加对归档状态的检查 - 同时在
getOutstandingReportsForUser函数中进行结果过滤
关键修改点包括:
- 检查报告是否已归档
- 确保只返回状态为"已提交"或更低状态的报告
- 验证报告与当前工作区的关联性
回归测试方案
为确保此类问题不再发生,团队设计了以下自动化测试场景:
- 创建新工作区并提交测试费用
- 删除该工作区
- 创建另一个工作区并提交新费用
- 尝试移动新费用时验证已删除工作区的报告不会出现在列表中
经验总结
这个案例展示了边界条件测试的重要性,特别是在涉及资源生命周期管理(创建/删除)的功能中。开发团队从中吸取了以下经验:
- 状态检查函数需要全面考虑所有可能的状态
- 删除操作可能产生连锁反应,需要全面验证相关功能
- 自动化测试应覆盖资源从创建到删除的完整生命周期
通过这次修复,Expensify/App的费用管理功能在边界条件处理上更加健壮,为用户提供了更一致和可靠的体验。
登录后查看全文
热门项目推荐
相关项目推荐
GLM-5智谱 AI 正式发布 GLM-5,旨在应对复杂系统工程和长时域智能体任务。Jinja00
GLM-5-w4a8GLM-5-w4a8基于混合专家架构,专为复杂系统工程与长周期智能体任务设计。支持单/多节点部署,适配Atlas 800T A3,采用w4a8量化技术,结合vLLM推理优化,高效平衡性能与精度,助力智能应用开发Jinja00
jiuwenclawJiuwenClaw 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。Python0238- QQwen3.5-397B-A17BQwen3.5 实现了重大飞跃,整合了多模态学习、架构效率、强化学习规模以及全球可访问性等方面的突破性进展,旨在为开发者和企业赋予前所未有的能力与效率。Jinja00
AtomGit城市坐标计划AtomGit 城市坐标计划开启!让开源有坐标,让城市有星火。致力于与城市合伙人共同构建并长期运营一个健康、活跃的本地开发者生态。01
electerm开源终端/ssh/telnet/serialport/RDP/VNC/Spice/sftp/ftp客户端(linux, mac, win)JavaScript00
项目优选
收起
deepin linux kernel
C
27
13
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
632
4.16 K
Ascend Extension for PyTorch
Python
471
567
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
932
835
🎉 (RuoYi)官方仓库 基于SpringBoot,Spring Security,JWT,Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.51 K
861
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
383
266
暂无简介
Dart
880
210
昇腾LLM分布式训练框架
Python
138
162
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
123
188
Oohos_react_native
React Native鸿蒙化仓库
JavaScript
327
382