Expensify Bug Report Potential Duplicate Error After Editing Expense Amount Explained
Hey guys! Let's dive into this Expensify bug report about a potential duplicate error that pops up after editing an expense amount. This is super important for ensuring the app works smoothly, so let’s break it down and see what’s happening. We'll cover all the details, from the bug's specifics to the expected and actual results, and even potential workarounds.
Discussion Category: Expensify, App
This issue falls squarely within the Expensify app itself, so it’s crucial we get this sorted. If you're interested in contributing, make sure to check out the contributing guidelines for onboarding. And, if you want to join the Slack channel, just shoot an email to contributors@expensify.com.
Version Number: 9.1.85-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://test-management.browserstack.com/projects/2148171/test-runs/TR-185/folder/12015289/39317386/801697779
Email or phone of affected tester (no customers): ibellicotest+1403@gmail.com
Issue reported by: Applause Internal Team
Device used: Motorola MotoG60 / Android 12 / Chrome ( mWeb / Hybrid app) - Windows 10 / Chrome
App Component: Money Requests
Action Performed: Steps to Reproduce the Bug
To really understand what’s going on, let's walk through the exact steps that trigger this bug. Here’s a detailed breakdown of the actions performed by the tester:
- Prerequisite: Make sure your account has at least one workspace. This is where your expenses and reports live, so it’s crucial for the test setup.
- Open the Expensify app: Pretty straightforward, right? Launch the app on your device.
- Open any workspace chat: This simulates a real-world scenario where you're discussing expenses within a team or group.
- Create a manual expense: This is where you’ll manually enter the details of an expense, like the amount and description.
- Create a new report: Reports are how you group expenses for submission and reimbursement. So, we’re setting up a fresh report to log these expenses.
- Tap on "Add Expense" on the just created report and create an expense similar to the previous one: This step is key – we're creating two similar expenses to mimic a potential duplicate scenario. Think of it like two receipts for similar amounts or purchases.
- Open the first created expense: Now, we're going back to the first expense we created.
- Tap on the "Amount" field and edit the amount: Here’s where the magic happens. We’re changing the amount of the first expense to see how the app handles potential duplicates.
- Return to chat: After editing, we go back to the chat view.
- Note that "Potential duplicate" error appears on the expense that wasn´t edited: This is the core of the bug. The error appears on the other expense, the one we didn’t even touch! This is definitely not the expected behavior.
- Navigate to "Inbox": Let's check the inbox to see if anything else is amiss.
- Note that a RBR (Report Billable Reminder) is displayed on workspace chat: This indicates there might be some notification or reminder related to the report in the workspace chat.
- Reopen workspace chat and open report of the expense with the "Potential Duplicate" error: We're going back to the report with the error to see if anything changes.
- Note that the error is cleared: Interestingly, the error disappears after reopening the report. This suggests the issue might be related to how the app refreshes or updates its state.
These steps are super crucial because they lay out exactly how to trigger the bug. When reporting bugs, detailed steps are your best friend! They help developers reproduce the issue and, more importantly, fix it.
Expected Result: What Should Have Happened
Okay, so what should have happened? After editing the amount on one of the duplicate expenses, the "Potential Duplicate" error shouldn’t appear on the remaining expense. The logic here is pretty straightforward: if the amounts are different, they’re not duplicates, right? The app should recognize this and not flag the unedited expense as a potential duplicate. Basically, we expect the app to be smart enough to understand that changing one expense doesn't automatically make the others duplicates.
This expected result is all about maintaining accuracy and avoiding false alarms. Users rely on Expensify to manage their expenses correctly, and getting duplicate errors when there aren't any can lead to confusion and wasted time. It messes with the user experience and could potentially cause real headaches when it comes to reconciling finances.
So, the key takeaway here is that the app needs to be more precise in identifying genuine duplicates and avoid flagging expenses incorrectly. Getting this right ensures that users trust the app and can use it efficiently without unnecessary errors popping up.
Actual Result: What Actually Happened (The Bug!)
Here's the kicker: When creating two similar expenses and editing the amount on one of them, the "Potential Duplicate" error appears on the expense that wasn’t edited, despite the amounts being different. This is the heart of the problem. Imagine changing one expense and then seeing another one flagged as a duplicate – super confusing! It’s like saying, "Hey, you changed this one, so the other one must be a duplicate too!" even if they're now totally different amounts.
The report further notes that the error is cleared after opening and closing the expense report. This is an interesting clue. It suggests that the error might be a display issue or a caching problem, where the app isn’t correctly updating its view until the report is refreshed. It's like the app needs a little nudge to realize, “Oh, wait, those amounts are different now!”
The issue is reproducible while online and also if the first expense is edited while offline. This is a crucial detail because it means the bug isn’t tied to network connectivity. It happens regardless of whether you’re online or offline, which points to a deeper logic issue within the app itself.
In summary, the actual result is a misidentification of potential duplicates, which leads to unnecessary error messages. This not only creates confusion for the user but also undermines the reliability of the app. We need Expensify to accurately flag duplicates, and this bug is a clear deviation from that expectation.
Workaround: Is There a Quick Fix?
Currently, the workaround is unknown. This means there isn't a simple, immediate solution users can implement to avoid this issue. When a bug like this pops up and there's no easy fix, it's crucial for the development team to jump on it. Users rely on workarounds to keep things running smoothly until a proper fix is rolled out. The fact that there isn't one here underscores the urgency of getting this bug resolved. Without a workaround, users might find themselves second-guessing the app's accuracy or spending extra time verifying their expenses, which is definitely not ideal. So, finding a solid workaround or pushing out a fix should be a top priority.
Platforms: Where Does This Bug Appear?
This bug isn't picky – it's showing up on multiple platforms, which makes it even more critical to address. Here’s a rundown of where the issue has been confirmed:
- [x] Android: App
- [x] Android: mWeb Chrome
- [ ] iOS: App
- [ ] iOS: mWeb Safari
- [ ] iOS: mWeb Chrome
- [x] Windows: Chrome
- [ ] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
As you can see, the bug is hitting Android (both the app and mWeb Chrome) and Windows Chrome users. This wide reach means a significant portion of users could be affected. The fact that it's on both the native Android app and the mobile web version suggests the issue might lie in the core logic of the app rather than being platform-specific.
The absence of reports from iOS platforms doesn't mean they're immune, but it does give us a clearer picture of where to focus initial debugging efforts. For a bug that impacts multiple platforms, a fix needs to be comprehensive to ensure a consistent experience for all users. This cross-platform nature elevates the severity of the bug and reinforces the need for a swift resolution.
Screenshots/Videos: Visual Proof
Visual evidence is super helpful for understanding bugs, and there's a screenshot/video attached to this report:
https://github.com/user-attachments/assets/59717dbb-fb81-438c-a955-83b2580f9aeb
Having visual proof allows developers to see the bug in action, which can speed up the debugging process. It's one thing to read about an error, but seeing it firsthand often provides additional context and can highlight nuances that might be missed in a written description. In this case, the screenshot or video likely shows the "Potential duplicate" error appearing on the incorrect expense, making the issue crystal clear.
When reporting bugs, always try to include screenshots or videos if possible. They’re invaluable for conveying the problem effectively and ensuring everyone is on the same page. For this particular bug, the visual confirmation strengthens the report and helps prioritize its resolution.