[HOLD for payment 2024-04-15] [Violations][$500] Scan - Category row shows violation briefly after the scan request is created

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 1.4.50-2
Reproducible in staging?: y
Reproducible in production?: y
Issue reported by: applause internal team

Action Performed:

Precondition:

• User is an employee of Collect workspace.
• The Collect workspace has toggled on "People must categorize expenses" for Categories on Old Dot.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create a scan request without category.
4. Go to request details page right after it is created.

Expected Result:

Category row will not show violation until after smartscanning is complete.

Actual Result:

Category row shows "missing category" violation briefly after the scan request is created.

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6410628_1710216751744.20240312_120823.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e13a4e6b1d86de89
• Upwork Job ID: 1770584960942833664
• Last Price Increase: 2024-03-20
• Automatic offers:
• eh2077 | Reviewer | 0
• bernhardoj | Contributor | 0

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[kavimuru]

We think this bug might be related to #wave-collect - RELEASE 1

cc @trjExpensify

[kavimuru]

@bfitzexpensify FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors.

[trjExpensify]

Hm, why wouldn't we show the category violation right away if categories are required on the workspace? 🤔 CC: @JmillsExpensify @cead22

[bfitzexpensify]

Yes, I think the bug here is that the violation disappears, not that it appears in the first place.

[bfitzexpensify]

@trjExpensify do you agree with this comment?

If so, I'll update the OP and send external

[trjExpensify]

Yeah, I agree with it insofar as I don't know why it's disappearing. This is violations related though, so one for #wave-control. :)

[cead22]

It looks like this is happening because we compute missingTag/missingCategory/tagOutOfPolicy/categoryOutOfPolicy/someTagLevelsRequired violations on the client, and when the request to OpenReport comes back, it clears the violations in Onyx which makes them disappear.

The reason violations are cleared is because we don't compute those violations when a transaction is a "partial transaction", meaning it's merchant is set to (none) and its amount is 0.

Let's make this issue external, have the contributors confirm that ^ is the root cause in their proposal, and see if adding a check for partial transactions in getViolationsOnyxData, or something along those lines fixes the issue

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01e13a4e6b1d86de89

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eh2077 (External)

[allgandalf]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Scan - Category row shows violation briefly after the scan request is created

What is the root cause of that problem?

We don't add a isScanning check before we fetch the violation:

App/src/components/ReportActionItem/MoneyRequestView.tsx

Lines 365 to 381 in a979d7d

	{shouldShowCategory && (
	<OfflineWithFeedback pendingAction={getPendingFieldAction('category')}>
	<MenuItemWithTopDescription
	description={translate('common.category')}
	title={transactionCategory}
	interactive={canEdit}
	shouldShowRightIcon={canEdit}
	titleStyle={styles.flex1}
	onPress={() =>
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(CONST.IOU.ACTION.EDIT, CONST.IOU.TYPE.REQUEST, transaction?.transactionID ?? '', report.reportID),
	)
	}
	brickRoadIndicator={getErrorForField('category') ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined}
	error={getErrorForField('category')}
	/>
	</OfflineWithFeedback>

RCA FOR Alternative Proposal

In getViolationsOnyxData, we check for the missing tag condition as:

App/src/libs/Violations/ViolationsUtils.ts

Line 128 in ba0816b

const hasMissingCategoryViolation = transactionViolations.some((violation) => violation.name === 'missingCategory');

But here we do not consider the state of the transaction where the transaction is still scanning and is in Pending state, so for the first few seconds we display a missing tag violation but then OpenReport api call returns the data and the violation error is cleared

What changes do you think we should make in order to solve the problem?

Add a isScanning check above.

const isScanning = hasReceipt && TransactionUtils.isReceiptBeingScanned(transaction);

Then update MenuItemWithTopDescription in MoneyRequestView as follows:

<MenuItemWithTopDescription 
             description={translate('common.category')} 
             title={transactionCategory} 
             interactive={canEdit} 
             shouldShowRightIcon={canEdit} 
             titleStyle={styles.flex1} 
             onPress={() => 
                 Navigation.navigate( 
                     ROUTES.MONEY_REQUEST_STEP_CATEGORY.getRoute(CONST.IOU.ACTION.EDIT, CONST.IOU.TYPE.REQUEST, transaction?.transactionID ?? '', report.reportID), 
                 ) 
             } 
-             brickRoadIndicator={getErrorForField('category') ? CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR :  
-  undefined}  
-             error={getErrorForField('category')} 
+             brickRoadIndicator={!isScanning && (getErrorForField('category') ?  
+ CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR : undefined)} 
+    error={isScanning ? undefined : getErrorForField('category')} 
         /> 

What alternative solutions did you explore? (Optional)

OR

We can directly update the getViolationsOnyxData for category check:

App/src/libs/Violations/ViolationsUtils.ts

Line 128 in ba0816b

const hasMissingCategoryViolation = transactionViolations.some((violation) => violation.name === 'missingCategory');

Update the above to:

const hasMissingCategoryViolation = transactionViolations.some((violation) => violation.name === 'missingCategory')
                                                                   && transaction?.status === CONST.TRANSACTION.STATUS.POSTED

[melvin-bot]

📣 @eh2077 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job

[melvin-bot]

📣 @bernhardoj 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app!

Offer link
Upwork job
Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review 🧑‍💻
Keep in mind: Code of Conduct | Contributing 📖

[bernhardoj]

PR is ready

cc: @eh2077

[allgandalf]

Let me summarize the expected result.

1. We shouldn't show the red dot on a scanning receipt, as that's a partial transaction, see comment
2. We don't want to show category violation when scanning is failed. In this case the transaction is still partial because we don't have all merchant and amount for it, see comment
3. For a failed scanning request, we should show category violation if the transaction isn't partial after editing, see comment

@GandalfGwaihir Sorry for the confusion caused.

Thanks for the explanation @eh2077 , appreciated 😄

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[JmillsExpensify]

Looks like we're close on the PR.

[eh2077]

The PR just hit staging.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.4.60-13 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Fix violation shows optimistically for a partial transaction #39034

If no regressions arise, payment will be issued on 2024-04-15. 🎊

For reference, here are some details about the assignees on this issue:

• @bernhardoj requires payment automatic offer (Contributor)
• @eh2077 requires payment automatic offer (Reviewer)

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@eh2077] The PR that introduced the bug has been identified. Link to the PR:
• [@eh2077] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@eh2077] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@eh2077] Determine if we should create a regression test for this bug.
• [@eh2077] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@bfitzexpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[eh2077]

Checklist

• [@eh2077] The PR that introduced the bug has been identified. Link to the PR: Adds Client-side Violations when creating money requests #32528
• [@eh2077] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment: https://github.com/Expensify/App/pull/32528/files#r1556996670
• [@eh2077] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion: N/A
• [@eh2077] Determine if we should create a regression test for this bug. Yes, we can add a regression test for this issue.
• [@eh2077] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Prerequisites:

• User is an employee of Collect workspace.
• The Collect workspace has toggled on "People must categorize expenses" for Categories

1. Go to the workspace policy expense chat
2. Create a new scan request that will fail
3. Open the expense report
4. Verify the request don't show a red dot
5. Open the transaction thread
6. Verify there is no Missing category error
7. Wait until the scan fails. Make sure both amount and merchant is empty.
8. Edit the description
9. Verify there is no Missing category error
10. Edit the amount/merchant
11. Verify Missing category error shows

Do you agree with the regression test above? 👍 or 👎

[cead22]

• The offending PR has been commented on, pointing out the bug it caused and why,

@eh2077 can you explain why that PR caused this regression?

[eh2077]

• The offending PR has been commented on, pointing out the bug it caused and why,

@eh2077 can you explain why that PR caused this regression?

Oh, my bad. Updated comment.

[cead22]

Thanks. I think that change actually happened before we were showing RBRs on partial transactions (I haven't confirmed). The linked PR was deployed in early Jan

[bfitzexpensify]

Payments complete - regression steps proposed in https://github.com/Expensify/Expensify/issues/388131. We're all done here, thanks everyone!