Workspace - Reimburse expenses- Rate equals 0 is displayed after offline changes on Reimbursement page

[kbecciv]

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

---

Action Performed:

1. Go to https://staging.new.expensify.com/ and login with expensifail account
2. Create a workspace (or it could be existing one)
3. Go to Reimburse expenses page of the workspace
4. Disable the internet connection
5. Change rate and and unit values
6. Enable internet connection
7. Refresh the page

Expected Result:

Rate and unit values should stay the same as were chosen offline

Actual Result:

Rate value changes to 0.

Platform:

Where is this issue occurring?

• Web

Version Number: 1.2.18.2

Reproducible in staging?: Yes

Reproducible in production?: No

Notes/Photos/Videos: Any additional supporting documentation

Bug5784086_video_2022-10-19_16-32-04-1.mp4

Issue reported by: Applause - Internal Team

[OSBotify]

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

[melvin-bot]

Triggered auto assignment to @cead22 (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[thienlnam]

Looks like we had a similar issue #10877 in the past

[thienlnam]

There does seem to be something wrong with customUnits in the policy

For some reason, we have the same element keyed multiple times in customUnits

When you make a change optimistically, it appears to only update the key under rates

Then we you go back online, the customUnits: null

There seems to a few things here -

1. Why are these keyed incorrectly
2. When we reconnect, we might be doing a SET somewhere and not fetching the policy customUnits

[thienlnam]

Okay, it actually seems like the keys are intentional so that is fine, though I'm unsure why there is onyxRates and rates which have the same values. I'm a little confused on how it's being set to null though. This is the order of responses that happens when you go back online after editing the custom units offline.

Reconnect app is where the customUnits is set to null
https://github.com/Expensify/Web-Expensify/blob/fc8ad875d159f0da57f09e362aa8a6172d4be1e3/lib/AppInit.php#L211-L212

But in the next two commands, is where we should have an updated custom unit.

It seems like because it's slow to merge a collection METHOD_MERGE_COLLECTION like we do in ReconnectApp, it might be happening after the updates and merges.

[thienlnam]

Out of the staging changes that could have impacted this, we might have uncovered some bugs due to the new onyx changes #11945 due to merge being faster, otherwise nothing else is sticking out.

I was able to get this to work by removing this line Expensify/Web-Expensify@fc8ad87/lib/AppInit.php#L211-L212 so that the customRate is never set to null, but it's still flipping between values (Fetches the old value first, but then shows the new value after)

I'm going to remove the deploy blocker since we this will have to update this with seperate changes, and the user can just see the updated rate by opening the screen again.

To sum up the issue, currently, the ReconnectApp API call when you come back online is merging null into CustomUnit here. This leads to the custom unit showing as 0 because METHOD_MERGE_COLLECTION takes longer than merge / set so our UpdateWorkspaceCustomUnitRate API pusher changes happen first, and then get overwritten with null. If you remove the customUnit: null we still have another issue where the new optimistic value in onyx is being overwritten somewhere in one of the Get / Reconnect api calls before UpdateWorkspaceCustomUnitRate API call is complete which leads to briefly seeing the old value, and then the new value once you come back online.

cc @amyevans / @jasperhuangg / @yuwenmemon
since you all worked on this code, do any of you have some additional context to this / does my investigation make sense?

[amyevans]

I think your investigation makes sense @thienlnam!

• Removing customUnit: null should clear up the overwriting with null problem
• The other issue you describe

the new optimistic value in onyx is being overwritten somewhere in one of the Get / Reconnect api calls before UpdateWorkspaceCustomUnitRate API call is complete

is documented in https://github.com/Expensify/Expensify/issues/229696 so I think we should prioritize finding a fix for that, though it sounds like it's a tricky problem

Curious if others agree though too!

[thienlnam]

I created https://github.com/Expensify/Web-Expensify/pull/35251 to fix the customUnit: null issue, and it sounds like the flickering issue is addressed in https://github.com/Expensify/Expensify/issues/229696

[melvin-bot]

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

[thienlnam]

customUnit: null PR has been merged, closing this one out and https://github.com/Expensify/Expensify/issues/229696 will take care of the rest