[$500] WS - Track distance rate is updated on device B even if device A was offline. No error message.

[izarutskaya]

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: 1.3.86-1
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @

Action Performed:

1. Login with the same account in the main testing device A and a secondary device B
2. Create workspace or go to the existing one
3. On the main testing device A navigate to Workspace settings > Reimburse expenses
4. Turn off the internet connection on the device A
5. Change the Distance rate to any number
6. Verify the field is grayed out after entering the number, indicating it's pending to be updated
7. On the Secondary device B navigate to Workspace settings > Reimburse expenses
8. Change the distance rate
9. On the main testing device A enable the internet connection
10. Verify that an error message is shown (red dot is present) and the track distance rate has changed to the one entered on device B

Expected Result:

An error message is shown (red dot is present) and the track distance rate has changed to the one entered on device B

Actual Result:

No error message. The track distance rate did not changed on device A but changed on device B.

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

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

Bug6241493_1697620057358.T3844333_iOS_Track_Distance_Rate_update_incorrect_way.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01e6380dfee0ad4833
• Upwork Job ID: 1714602139599908864
• Last Price Increase: 2023-12-05
• Automatic offers:
• Ollyws | Reviewer | 28013831
• bernhardoj | Contributor | 28013833

Issue Owner

Current Issue Owner: @maddylewis

[melvin-bot]

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

[melvin-bot]

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

[melvin-bot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[melvin-bot]

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

[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 @nkuoch (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[chiragkcodes]

Identified the PR that introduced this issue - PR
Due to changes in the PR, we are not sending lastModified in policy update payload while updating reimbursement rate and unit when Offline
This is causing the queued request (after coming online) to override the latest rate and unit.

Note: Reverting PR will re-introduce Issue

[chiragkcodes]

Proposal

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

WS - Track distance rate is updated on device B even if device A was offline. No error message.

What is the root cause of that problem?

Due to changes in the #29700, when Offline - we are not sending lastModified in policy update payload while updating reimbursement rate and unit (UpdateWorkspaceCustomUnitAndRate command).

This is causing the queued request to override the latest rate and unit after coming online.

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

Reverting the problematic PR if #28942 is not deploy blocker.
Need to explore other option to solve original issue.

What alternative solutions did you explore? (Optional)

NA

[AmjedNazzal]

@narefyev91 @mountiny I'm not sure I understand this one, can you help me understand why this is an issue and a deploy blocker? what exactly is the issue when a pending offline change overrides a change made on the same account that is online? because I knew this will obviously be the resulting behaviour and thought it was okay

[francoisl]

The idea is that we want to avoid multiple devices from overriding changes from each other while one is offline. I could be swayed either way that this is actually a bug or not, but it's an edge case so I'll remove the blocker label for now and we can have a broader discussion on whether we want to fix it later.

---

For reference, here's the error that you get with the production version

[AmjedNazzal]

@francoisl I see, thank you for the clarification, if this kind of edge case might be problematic I can look into approaching my solution differently in my PR or any other approach that is appropriate here.

[melvin-bot]

Current assignee @Ollyws is eligible for the External assigner, not assigning anyone new.

[bernhardoj]

Proposal

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

The track distance rate can be updated while offline even though we already updated it from another device/client. It should give an error message because the data sent from the first device while offline is the old data (old lastModified)

What is the root cause of that problem?

We prevent the user from updating the track distance data if the sent lastModified over API is behind the lastModified in the server. However, while offline, we don't send the lastModified data.

App/src/libs/actions/Policy.js

Line 960 in 5654980

...(!networkStatus.isOffline && {lastModified}),

It's to fix this issue, but the real issue is on the BE. #29853 (comment)

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

The BE issue is fixed, so we should always send the lastModified data.

I have retested #28942 after applying the solution and the issue is gone

there is a proposal here with the same FE solution, but I also help with the BE fix

[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]

@francoisl, @Ollyws, @maddylewis Whoops! This issue is 2 days overdue. Let's get this updated quick!

[francoisl]

@bernhardoj's proposal looks good to me, let's roll with that.

[melvin-bot]

📣 @Ollyws 🎉 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: @Ollyws @francoisl

[bernhardoj]

@maddylewis I think this is ready for payment.

[melvin-bot]

This issue has not been updated in over 15 days. @francoisl, @Ollyws, @maddylewis, @bernhardoj eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[francoisl]

@maddylewis small bump on payment when you a chance.

[maddylewis]

Plz move to daily when ready for payment - ty! Reviewing now :)

[maddylewis]

@bernhardoj paid / offer sent to @Ollyws

[maddylewis]

@Ollyws is also paid! 👍

[bernhardoj]

@maddylewis hi, sorry, but I just rechecked the Upwork offer and looks like it's not paid yet for me. Can you please recheck this on your end?

[francoisl]

@maddylewis bump on the above ^