Held expense - RBR appears on expense preview in the main chat then disappears

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.90-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): applausetester+100106kh@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: Mac 15.0 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open DM with user that has no unsettled expense.
3. Submit an expense to the user.
4. In the main chat, right click on the expense preview > Hold.
5. Enter a reason and save it.
6. Note that the expense preview in the main chat displays RBR.
7. Click on the expense preview.
8. Go back to the main chat.

Expected Result:

RBR on the expense preview in the main chat should persist after visiting expense preview and returning to main chat.

Actual Result:

RBR on the expense preview in the main chat disappears after visiting expense preview and returning to main chat.

Workaround:

Unknown

Platforms:

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6725842_1738046895041.20250128_144534.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @RachCHopkins (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @mjasikowski (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[mjasikowski]

Reproduced locally

[mjasikowski]

@IuliiaHerets is this a regression? testing on 90.0.89-8 the RBR is not showing in the preview at all, so I assume it's just a bug in #55655.

If it's just a bug in the PR above I'll demote it.

[brunovjk]

Investigating... @thelullabyy Do you have any idea what's causing it?

[mjasikowski]

I'm demoting this. While the functionality seems to be incomplete, it's just a UI problem and it was worse in the previous release. Nevertheless, this needs fixing.

[brunovjk]

I've been investigating, and this issue seems to be related to the server response:

Screen.Recording.2025-01-29.at.10.27.40.mov

However, I wonder about the expected behavior of LHN. When we "hold" a transaction in a workspace chat, the RBR appears in both LHN and the preview. In a DM chat, the RBR should appear in LHN as well, in addition to the report preview, of course, correct?

cc: @mjasikowski @cristipaval

[mjasikowski]

@cristipaval do you know what the expected behavior should be? I'm unfamiliar with the flow unfortunately.

[melvin-bot]

@mjasikowski, @RachCHopkins Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mjasikowski]

@cristipaval friendly bump

[cristipaval]

SOrry @mjasikowski, I missed it. Yes, the RBR should be shown in LHN as well, when it is displayed on the IOU preview

[RachCHopkins]

Thanks @mjasikowski I'm just taking a back seat until someone needs paying!

[thelullabyy]

RBR on the expense preview in the main chat disappears after visiting expense preview and returning to main chat.

Root cause:

• When an expense belongs to a 1:1 DM and is put on hold, a new hold violation is always added optimistically:

App/src/libs/actions/IOU.ts

Line 9196 in c52ed2b

const newViolation = {name: CONST.VIOLATIONS.HOLD, type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true};

This causes the ReportPreview to show RBR in step 6..

• However, after step 7, calling OpenReport triggers the backend to set the violation to null. As a result, RBR disappears from the expense preview in the main chat after visiting the expense preview and returning.

Solution:

Solution 1:

If the backend's response is the source of truth, then putting an expense on hold in a 1:1 DM should not add a hold violation. To fix this, update:

App/src/libs/actions/IOU.ts

Line 9196 in c52ed2b

const newViolation = {name: CONST.VIOLATIONS.HOLD, type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true};

to:

    const parentReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${iouReport?.parentReportID}`];
    const newViolation = isPolicyExpenseChat(parentReport) ? {name: CONST.VIOLATIONS.HOLD, type: CONST.VIOLATION_TYPES.VIOLATION, showInReview: true} : {};

Solution 2:

If a violation should always be added regardless of whether the expense belongs to a policy expense chat, then this is a backend bug. The backend should ensure that after step 7, it does not set the violation to null.

[cristipaval]

@cead22 @pecanoro, at first glance on the Design Doc related to violations, it seems that the backend handles mainly the policy violations, thus calculating the violations for expense reports only. Do I get this right?

TLDR: The issue here is that RBR is missing on the IOU reports with held transactions, in 1:1 DM chats. Should we fix this in the App code by checking if there are held transactions on the IOU report?

[pecanoro]

So are you saying we do it optimistically for some reports but not all? I am a bit confused about what we are missing here haha

[cead22]

I think Cristi is just asking about violations for IOUs. For the violations project we only took into account the policy violations that we support in old dot, which are violations on expense report and invoices.

AFAIK we didn't add support for held transactions on IOU reports. I don't know off the top of my head if it's better to add it to the front end or the backend

[cristipaval]

I think Cristi is just asking about violations for IOUs.

Yes, sorry for the confusion, @pecanoro.

I don't know off the top of my head if it's better to add it to the front end or the backend

I don't know of any other violations for IOUs other than held transactions. The others are related to policy rules that are not applicable in 1:1. So, I would start simple with logic in the client to show the RBR when the report has held transactions and move them to Auth later if necessary.

What do you think, @pecanoro and @cead22?

[cead22]

So, I would start simple with logic in the client to show the RBR when the report has held transactions and move them to Auth later if necessary.

That sounds good. The only caveat here is that we'll be adding front end logic for violations (since held expenses on IOU behave like violations, at least when it comes to the RBR) that is different from the logic that exists today.

Today for violations we have the backend set transactionViolations_,<tID> keys in onyx with the violation data, and we have the front end check for that data.

So I'm curious how your proposal would work in a bit more detail so we can better compare the options

[cristipaval]

The only caveat here is that we'll be adding front end logic for violations (since held expenses on IOU behave like violations, at least when it comes to the RBR) that is different from the logic that exists today.

Hmm, now this makes me hesitant about adding logic to the App code, as it would be inconsistent with the logic for the expense reports that check for transaction violations in Onyx.

So I'm curious how your proposal would work in a bit more detail so we can better compare the options

We show the RBR if the report hasErrors (code here), which is true if there are violations. I would update the condition also to show the RBR if the chat is a DM and the report has held transactions. But again, since there is already logic in the backend for showing violations when there are held transactions, maybe it is cleaner to make it work for IOUs as well and keep them consistent with the expense reports 🤔

[pecanoro]

You should be able to compute violations in any report has long as it has transactions on it

[cead22]

But again, since there is already logic in the backend for showing violations when there are held transactions, maybe it is cleaner to make it work for IOUs as well and keep them consistent with the expense reports 🤔

You should be able to compute violations in any report has long as it has transactions on it

Yeah that sounds better to me as well

[cristipaval]

Thank you both, @cead22 and @pecanoro 🙏

[mallenexpensify]

Made this a MEDIUM status cuz of this from above. Comment if you think it should be higher.

it's just a UI problem and it was worse in the previous release. Nevertheless, this needs fixing.

Also.. if this needs a C+, can you assign @brunovjk since they've been helpful and have context. thx

[mallenexpensify]

Moving this to #expense (cuz it's specific to a held expense). @dylanexpensify , let me know if you disagree.
Also.. we have an issue held on this one, so it'd be good to keep this one moving forward

• [HOLD #55844] [$250] Expenses - RBR is missing in expense preview for a preview with a held and not held expenses #55263

[RachCHopkins]

Update above.

[brunovjk]

Any updates for us @cristipaval? Thank you.

[cristipaval]

I've been busy with other things lately. I'll work on this one today or tomorrow.