[$250] Distance- Rate added offline seen grayed out going online then back offline

[lanitochka17]

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.53-1
Reproducible in staging?: Y
Reproducible in production?: Y
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: N/A
Email or phone of affected tester (no customers): applausetester+ck1024@applause.expensifail.com
Issue reported by: Applause - Internal Team

Issue found when executing PR #51159

Action Performed:

Precondition: Have both perdiem and distance rates set up in OldDot.

1. Open the ND app
2. Go to Settings >> Workspaces >> Workspace >> Distance rates
3. Go offline
4. Add a new rate
5. Delete one of the distance rate which was added previously (the rate added online in precondition)
6. Go online (Note: New rate gets bolded (active state) & other rate gets deleted)
7. Go back offline (Note: The new rate which was active gets grayed out again)

Expected Result:

The new rate (added offline) which is active/bolded after going back online should stay bolded after user go offline again

Actual Result:

The new rate added offline becomes active when going online. But seen grayed out when user go offline again after the distance rate is completely active
The same rate seen grayed out every time user go offline

Workaround:

Unknown

Platforms:

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

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

Screenshots/Videos

Add any screenshot/video evidence

Bug6644637_1729782903129.Recording__117.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021849920398995761024
• Upwork Job ID: 1849920398995761024
• Last Price Increase: 2024-11-29

Issue Owner

Current Issue Owner: @allgandalf

[melvin-bot]

Triggered auto assignment to @lschurr (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.

[lanitochka17]

@lschurr 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

[CyberAndrii]

Edited by proposal-police: This proposal was edited at 2024-10-31 14:40:48 UTC.

Proposal

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

Rate added offline seen grayed out going online then back offline

What is the root cause of that problem?

This issue occurs because all rates (even those not being deleted) are included in optimisticData and successData

App/src/libs/actions/Policy/DistanceRate.ts

Lines 488 to 504 in 476ad6b

	for (const rateID of Object.keys(currentRates)) {
	if (rateIDsToDelete.includes(rateID)) {
	optimisticRates[rateID] = {
	...currentRates[rateID],
	enabled: false,
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	};
	failureRates[rateID] = {
	...currentRates[rateID],
	pendingAction: null,
	errors: ErrorUtils.getMicroSecondOnyxErrorWithTranslationKey('common.genericErrorMessage'),
	};
	} else {
	optimisticRates[rateID] = currentRates[rateID];
	successRates[rateID] = currentRates[rateID];
	}
	}

Later, when successData is applied, it unintentionally overrides changes made by the CreatePolicyDistanceRate request.

The flow is as follows:

1. Rate B is created: optimisticData is applied
2. Rate A is deleted: optimisticData is applied
3. Go online
4. Rate B successData is applied: it sets the pendingAction prop on Rate B to null (correct)
5. Rate A successData is applied: it sets the pendingAction prop on Rate B back to the previous value (incorrect)

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

We should remove this else block:

App/src/libs/actions/Policy/DistanceRate.ts

Lines 500 to 503 in 476ad6b

	} else {
	optimisticRates[rateID] = currentRates[rateID];
	successRates[rateID] = currentRates[rateID];
	}

It was added in #38237 when this feature was first implemented. A few months later it was moved from Policy.ts to DistanceRate.ts to reduce the file size. There don't seem to be any discussions about it so I believe it was added by mistake and overlooked during the review.

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

@lschurr, @allgandalf Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[lschurr]

@allgandalf could you review the proposal?

[allgandalf]

This issue occurs because all rates (even those not being deleted) are included in optimisticData and successData.

@CyberAndrii can you dig more into the RCA? there must be a reason that we included those rates there. please try to find the PR and intension of the data added there

[CyberAndrii]

Proposal updated

• Updated RCA and solution.

It turns out that removing the spread of non-modified properties (e.g. ...currentRates[rateID]) is not required, as I thought, but it is still weird. All it needs is customUnitRateID property.

cc @allgandalf

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[lschurr]

@allgandalf could you review the updated proposal?

[lschurr]

Bumped in Slack - https://expensify.slack.com/archives/C01GTK53T8Q/p1730735812544159

[melvin-bot]

@lschurr, @allgandalf Eep! 4 days overdue now. Issues have feelings too...

[allgandalf]

@CyberAndrii can you please provide me a test branch? I would like to test some things before moving forward with your solution (FYI, your RCA sounds correct to me)

[CyberAndrii]

@allgandalf just this 1 change

[allgandalf]

testing the proposed change ....

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

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

[melvin-bot]

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

[allgandalf]

@CyberAndrii thanks a lot, your RCA makes a lot of sense to me and is indeed correct.

I have asked the original author https://github.com/Expensify/App/pull/42786/files#r1837785964 about why that block was introduced, we should have an update by tomorrow before going with your solution

[allgandalf]

Update: the original author is OoO, I will bump them again next week

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[wildan-m]

Proposal

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

Distance Rate displayed as grayed out when transitioning from offline to online and back to offline.

What is the root cause of that problem?

We cloned entire value including pendingAction when we create successData here

App/src/libs/actions/Policy/DistanceRate.ts

Line 502 in 99bf554

successRates[rateID] = currentRates[rateID];

When we add new distance rate and delete existing distance rate in offline, the add pendingAction will be cloned in that code, this will create issue if the create request completed, because that pendingAction is not cleared.

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

We cleared pendingAction when createPolicyDistanceRate success

App/src/libs/actions/Policy/DistanceRate.ts

Lines 199 to 201 in 99bf554

	[customUnitRate.customUnitRateID ?? '']: {
	pendingAction: null,
	},

That's why the issue not occurred if we reverse the order: delete rate A then add new rate B.

We should also clean that pendingAction when deletePolicyDistanceRates success

Change:

App/src/libs/actions/Policy/DistanceRate.ts

Line 502 in 99bf554

successRates[rateID] = currentRates[rateID];

To

            successRates[rateID] = {
                ...currentRates[rateID],
                pendingAction: null,
            };

Branch for this solution

What alternative solutions did you explore? (Optional)

N/A

[allgandalf]

still pending (comment)

[twisterdotcom]

Relabelling as Lauren is OOO now.

[melvin-bot]

Triggered auto assignment to @puneetlath (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.

[allgandalf]

Not overdue, waiting for reply

[melvin-bot]

@puneetlath @lschurr @allgandalf 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!

[allgandalf]

waiting for reply, i will bump once again

[twisterdotcom]

@dangrous answered here: https://github.com/Expensify/App/pull/42786/files#r1838227400. What are we still waiting for?

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[allgandalf]

Oops my bad, I didn't update the slack link in this issue, the original author was neil here, and they were OoO that week, I will bump them again on slack.

[melvin-bot]

@puneetlath, @lschurr, @allgandalf Whoops! This issue is 2 days overdue. Let's get this updated quick!

[allgandalf]

Not overdue

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[melvin-bot]

@puneetlath, @lschurr, @allgandalf Whoops! This issue is 2 days overdue. Let's get this updated quick!