[HOLD for payment 2025-01-28] Per diem - Subrate quantity field has no limitation

[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.81-0
Reproducible in staging?: Y
Reproducible in production?: Unable to check
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: #54252
Email or phone of affected tester (no customers): applausetester+2390223d@applause.expensifail.com
Issue reported by: Applause - Internal Team
Component: Money Requests

Action Performed:

Precondition:

• Workspace has per diem rates

1. Go to staging.new.expensify.com
2. Go to workspace chat
3. Click + > Submit expense > Per diem
4. Select a country, select valid date and time and click Next
5. Select a subrate
6. On quantity field, enter a lot of numbers
7. Click Next

Expected Result:

There should be limitation on the quantity field

Actual Result:

There is limitation on the quantity field
When entering big number and reaching the next page, the quantity field shows xe+y format

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

Bug6707542_1736193313242.20250107_035124.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @dangrous (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

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

[aldo-expensify]

Was able to reproduce, but this seems more like a front end issue.
It is not possible to create PerDiem expense in production yet.

[dangrous]

@ishpaul777 @Gonals @c3024 @shubham1206agra I see you worked on the implementation of Per Diem expenses.

Is this a big enough bug to block deploy, or can we move forward? (is the feature under beta?)

Also, does one of you want to tackle this?

Thanks!

[ishpaul777]

👋Hey @dangrous, I was not involved in the PR

[c3024]

I don't think this is significant enough to block deploy. Moreover, this is behind a beta.

We can restrict each subrate quantity to less than the trip length with getTimeDifferenceIntervals of PerDiemRequestUtils and validate it.

@shubham1206agra , I think this can be changed in the follow-up PRs.

@dangrous, please assign us. Thanks!

[shubham1206agra]

@c3024 I don't think restriction based on getTimeDifferenceIntervals is a good idea.

I am going to introduce an upper bound limit of 12 digits. Since it will guarantee the number will be less than Number.MAX_SAFE_INTEGER, which will help us store lossless integers.