Reimburse expenses - Error continues to appear when changing the rate after it was modified

[kbecciv]

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

---

Issue found when executing PR #12162

Action Performed:

1. Navigate to any existing workspace on device A > Reimburse expenses. Go offline.
2. Switch to device B. Sign into the same account, and navigate to the same workspace > Reimburse expenses.
3. Edit the Rate input
4. Observe it shows in the pending state
5. Switch back to device A. Make sure you're still offline. Edit the same rate field.
6. Go back online on device A
7. Observe the unit field fails to update because the workspace was modified while you were offline, displaying the RBR and error message
8. Attempt to update the rate field again while online.

Expected Result:

You are able to modify the field and no errors show.

Actual Result:

Error continues to appear when changing the rate after it was modified offline

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web
• iOS
• Desktop App
• Mobile Web

Version Number: 1.2.23.7

Reproducible in staging?: Yes

Reproducible in production?: Yes

Email or phone of affected tester (no customers): any

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Bug5805014_12162_Web_2.mp4

Bug5805014_Record_2022-11-03-20-31-12__1_.1.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal

Slack conversation:

View all open jobs on GitHub

[melvin-bot]

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

[jasperhuangg]

This was my PR so I can investigate. Seems something changed between when I tested it locally and when it was deployed.

[jasperhuangg]

Hmm, looking at the issue it's probably best to wait for #12219 to be merged + deployed first so we can be more sure of what the issue is. I think the offline client may seem to have the wrong value after coming back online because the order of writes and reads is incorrect.

This happened for me locally, but after pulling the changes from #12219 that seemed to fix things since it ensures read requests run last.

Context for Web PR

I did notice a separate issue while having those changes checked out, but I think I know how to rectify it and can open a separate web PR. Basically, we also need to send back the current custom unit rate data when we error out, that way the client can display the current custom unit rate data as soon as we come back online and display the error.

[trjExpensify]

Sheesh, fun one! Okay cool, so we should mark this as internal right?

[jasperhuangg]

sure, I can also QA both PRs since I have the most context about what to look out for

to clarify, for this issue we currently have:
https://github.com/Expensify/Web-Expensify/pull/35433
which is held on #12219, which has been approved already and should be merged soon

[trjExpensify]

#12219 has merged, so #35433 should come off hold imminently.

[mvtglobally]

Issue not reproducible during KI retests. (First week)

[trjExpensify]

#12219 is on staging. #35433 is reviewed, and should come off hold imminently after the prod deploy.

[jasperhuangg]

https://github.com/Expensify/Web-Expensify/pull/35433 was just deployed to prod an hour ago. Testing this out again

[jasperhuangg]

Hmm it seems like now I can't even get the error to appear, strangely the API just accepts the new updates from the client that was offline. Perhaps something has changed since https://github.com/Expensify/Web-Expensify/pull/35433 was being deployed, I'll investigate.

Screen.Recording.2022-11-15.at.11.23.32.AM.mov

[mvtglobally]

Issue not reproducible during KI retests. (Second week)

[jasperhuangg]

Actually, the errors do show up correctly locally, but they don't on staging or prod yet, I'm going to close this out for the time being and try it once the next few deploys go out. If it crops up again I'll reopen.

[kbecciv]

Issue is reproduced today with build 1.2.31.7

Screenrecorder-2022-11-24-23-42-19-718.mp4

[melvin-bot]

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

[jasperhuangg]

Taking a look into this one today!

[jasperhuangg]

@kbecciv it seems to actually be working as expected when I tested it on v1.2.32-1

Screen.Recording.2022-11-28.at.9.28.45.AM.mov

• The final values on both clients are correct. Don't mind the replay effect, that's tackled in [Tracking] "Replay effect" when sequential actions are taken offline, and user subsequently comes online #12775. Subsequent updates to the values also work.
• It seems to be working in the screen recording you provided? Without knowing what the values on the other client are, I have no way of verifying if the behavior is correct for the client coming back online.
• For these types of issues that require two clients to be used, can you please provide both clients in the screen recording in the future?