[$250] Held expense - Green payment button appears briefly when paying held expense

[IuliiaHerets]

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: 9.0.74-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp #53117
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Submit an expense.
4. Go to transaction thread.
5. Click on the report header > Hold > Hold the expense.
6. Click on the header subtitle to return to main chat.
7. Click on the pay button dropdown > Pay elsewhere.
8. Click Pay elsewhere.
9. Click Pay all.

Expected Result:

Green payment button will not appear briefly when paying held expense.

Actual Result:

Green payment button appears briefly when paying held expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6690447_1733876458137.20241211_081228.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021866793490879654211
• Upwork Job ID: 1866793490879654211
• Last Price Increase: 2024-12-11

Issue Owner

Current Issue Owner: @Julesssss

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @OfstadC (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]

💬 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.

[Julesssss]

This is a brief UI issues, so I am removing blocker.

[melvin-bot]

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

[melvin-bot]

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

[mkzie2]

Proposal

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

Green payment button appears briefly when paying held expense.

What is the root cause of that problem?

The button will be displayed with a success color if we don't have any requests that have been held.

App/src/components/ReportActionItem/ReportPreview.tsx

Line 537 in c1454f7

shouldUseSuccessStyle={!hasHeldExpenses}

When we pay held expenses, the held transaction is unheld in optimistic data then shouldUseSuccessStyle is changed from false to true briefly while the animation is running.

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

We should delay calling the API a bit to wait until the animation is complete if we paid in full and the startAnimation exist

const shouldDelay = full && !!startAnimation;
if (shouldDelay) {
    setTimeout(() => {
        IOU.payMoneyRequest(paymentType, chatReport, moneyRequestReport, full);
    }, CONST.ANIMATION_PAID_DURATION);
} else {
    IOU.payMoneyRequest(paymentType, chatReport, moneyRequestReport, full);;
}

App/src/components/ProcessMoneyReportHoldMenu.tsx

Line 77 in c1454f7

IOU.payMoneyRequest(paymentType, chatReport, moneyRequestReport, full);

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[bernhardoj]

Proposal

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

Pay button becomes green again when the paid animation is running.

What is the root cause of that problem?

The button becomes gray when there are held expenses.

App/src/components/ReportActionItem/ReportPreview.tsx

Lines 536 to 537 in c1454f7

	<AnimatedSettlementButton
	shouldUseSuccessStyle={!hasHeldExpenses}

When we pay the expense, it becomes unheld, so the button turns green again while the animation is running.

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

We can prevent the button props to be updated. First, create a new ref.

const frozenProps = useRef();

When the animation runs, set the rest of the props to the frozenProps.

App/src/components/SettlementButton/AnimatedSettlementButton.tsx

Lines 57 to 62 in c1454f7

	useEffect(() => {
	if (!isPaidAnimationRunning) {
	resetAnimation();
	return;
	}
	buttonScale.set(withTiming(0, {duration: CONST.ANIMATION_PAID_DURATION}));

App/src/components/SettlementButton/AnimatedSettlementButton.tsx

Line 16 in c1454f7

function AnimatedSettlementButton({isPaidAnimationRunning, onAnimationFinish, isDisabled, ...settlementButtonProps}: AnimatedSettlementButtonProps) {

useEffect(() => {
    if (!isPaidAnimationRunning) {
        frozenProps.current = undefined;
        resetAnimation();
        return;
    }
    frozenProps.current = settlementButtonProps;

Then, pass the frozen props to the settlement button

<SettlementButton
    // eslint-disable-next-line react/jsx-props-no-spreading
    {...(frozenProps.current ?? settlementButtonProps)}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

[thesahindia]

@bernhardoj's proposal looks good to me!

🎀 👀 🎀 C+ reviewed

[melvin-bot]

Current assignee @Julesssss is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new.

[thesahindia]

@mkzie2, we prefer not to use setTimeout unless it is absolutely necessary.

[melvin-bot]

@Julesssss, @OfstadC, @thesahindia Whoops! This issue is 2 days overdue. Let's get this updated quick!

[mkzie2]

I see we're planning to revert this feature here, we should hold on this.

[Julesssss]

As mentioned by @mkzie2, this is held.

[melvin-bot]

@Julesssss @OfstadC @thesahindia this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[Julesssss]

Currently held

[Julesssss]

Still held

[melvin-bot]

@Julesssss @OfstadC @thesahindia this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[Julesssss]

No change on the status of the blocker.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[Julesssss]

Not overdue

[Julesssss]

Awaiting further tests, we can hopefully close this soon

[mvtglobally]

Issue not reproducible during KI retests. (Second week)