Reimburse expenses - The milage rate automatically changes to the initial value

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

---

Issue found when executing PR #10692

Action Performed:

1. Go to URL https://staging.new.expensify.com/
   and login
2. Create a New Workspace
3. Go to Settings -> Workspace -> Reimburse expenses
4. Edit the milage rate

Expected Result:

The mileage rate should change after the changes

Actual Result:

The milage rate automatically changes to the initial value

Workaround:

Unknown

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: 1.1.97.2

Reproducible in staging?: Yes

Reproducible in production?: No

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

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

Notes/Photos/Videos: Any additional supporting documentation

Bug5718603_Recording__1786.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause - Internal Team

Slack conversation:

View all open jobs on GitHub

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

[chiragsalian]

Ah poop, the mistake is here where we forgot to think about migration to support older data. cc @amyevans.

We could push up a fix to support the older data but I think maybe it's better to push forward and CP these two,
#10692, and
#10557 (for this one, the related web PRs are already live and the PR is in final review so I think it should be simple enough to CP). cc @neil-marcellini

[amyevans]

cc @jasperhuangg as well since looks like there's more conflicts when trying to merge main into your App branch in #10557

[luacmartins]

@amyevans do you wanna take this blocker over from Chirag, since you seem to know how to fix it?

[Julesssss]

Bumping @amyevans. But I can also take over this as I'll be working on deployers until we release today.

[amyevans]

We'll need to cherry pick #10557, but it needs to be updated with main first and then I can review again before we ship it. Does that plan sound okay? Going to comment in the PR

[Julesssss]

but it needs to be updated with main first

Just wanted to check that this is necessary. As if we mergemain wouldn't your PR include a bunch of unwanted commits when we CP?

[amyevans]

wouldn't your PR include a bunch of unwanted commits when we CP?

Hmm I don't think so, I'm not entirely sure how the cherry pick script works though to be honest. But I would expect that it just cherry picks each individual commit in the PR.

But yes by that logic, being up to date with main doesn't actually matter

[Julesssss]

We'll get back to this tomorrow once the provisioning build has been confirmed to be working.