Expensify: Fix GBRd Chats For On-Hold Expenses

Hey everyone! Today, we're diving into a quirky issue we've discovered in Expensify: expense chats getting automatically marked as GBRd (Going Back to Review) even when all the expenses within the reports are on hold. This can be a bit of a headache, so let's break down the problem, the expected behavior, and what's actually happening.

The Issue: GBRd Chats with On-Hold Expenses

So, the main problem here is that expense chats are being marked as GBRd even when all the associated expenses are on hold. This means that approvers are getting notifications and having to revisit these chats unnecessarily. In essence, the system is flagging these chats for review even though there's nothing immediately actionable since the expenses are on hold. This can lead to confusion, wasted time, and a less-than-ideal user experience. We need to ensure that the system intelligently recognizes the “on hold” status and avoids triggering the GBRd process when there’s no urgent action required. Think about it like this: if all the doors are locked, you wouldn’t expect the alarm to go off, right? Similarly, if all expenses are on hold, the chat shouldn’t be flagged as needing immediate review.

We're talking about a scenario where you've submitted expense reports, but all the expenses within those reports are marked as “on hold.” Now, when the approver logs in, they see that the associated chat for these reports has been flagged as GBRd (Going Back to Review). This is where the problem lies. Ideally, if all expenses are on hold, the chat shouldn't be flagged, saving everyone time and reducing unnecessary notifications. Imagine you’re swamped with other tasks and you see a notification about an expense report needing your attention. You click on it, only to find that all the expenses are on hold. That’s a bit frustrating, right? This issue can lead to a lot of such small frustrations that add up over time, making the whole expense management process feel less smooth and efficient.

This issue was reported by @quinthar, and the conversation around it is happening in the #Convert Slack channel. If you're interested in digging deeper into the technical aspects, you can check out the logs on Stack Overflow. The version number where this issue was identified is 9.1.89-1, and it's reproducible in both staging and production environments. So, it’s not just a one-off glitch; it’s a consistent behavior that needs addressing. The fact that it’s reproducible in both environments means that the issue is likely in the core logic of how the system handles on-hold expenses and chat flagging, rather than being tied to specific configurations or data sets. This makes it easier to investigate and fix, as the developers can reliably recreate the problem and test their solutions.

Expected vs. Actual Result

The expected result is pretty straightforward: if all expenses across all reports awaiting approval are marked as on hold, the chat should not be GBRd. It's like saying,