[$250] Dialpad shows up twice when creating expense from FAB

[m-natarajan]

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.2.66-0
Reproducible in staging?: Needs Reproduction (Unable to repeoduce)
Reproducible in production?: Needs Reproduction
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: @mananjadhav
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Tested with a new account.
2. Open the mobile native app or in mobile browser
3. Create a workspace (Disable submission frequency in workflow)
4. Go to the main screen
5. Click on FAB > Create Expense
6. Number input will show up, enter any amount and click next

Expected Result:

You should be able to see the other fields form for the expense

Actual Result:

The number input screen shows up again.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Platforms Tested:

On which of our officially supported platforms was this issue tested:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

ScreenRecording_12-01-2025.22-08-45_1.MP4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021998211924821723916
• Upwork Job ID: 1998211924821723916
• Last Price Increase: 2025-12-09

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

Triggered auto assignment to @strepanier03 (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[Krishna2323]

I can reproduce the issue on the simulator as well. The steps are a bit different: I see the confirmation page, and then if I go back and save the amount, the amount page shows up again.

Monosnap.screencast.2025-12-02.00-06-37.mp4

[abzokhattab]

Proposal

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

When creating an expense from FAB, going back from the confirmation page and saving the amount again causes the amount/dialpad page to show up again instead of returning to confirmation.

What is the root cause of that problem?

• When navigating back to confirmation after the user has already visited it, the code in IOURequestStepAmount calculates the chatReportID using transaction?.reportID

App/src/pages/iou/request/step/IOURequestStepAmount.tsx

Line 301 in 4169a2e

const chatReportID = selectedReport?.chatReportID ?? iouReportID;

• This value can be UNREPORTED_REPORT_ID ('0') when auto-reporting is disabled
• The confirmation page has a useEffect that validates if transaction.participants[0].reportID === reportID

  App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

  Line 349 in 4169a2e

  ? transaction?.participants?.at(0)?.reportID === reportID || (!transaction?.participants?.at(0)?.reportID && transaction?.reportID === reportID)

• When the route has reportID = '0' but the participant has the actual workspace chat report ID, this check fails
• The failed check triggers startMoneyRequest() which navigates to a fresh create flow, showing the amount page again
  

  App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

  Line 361 in 4169a2e

  startMoneyRequest(

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

• when returning from the confirmation page (isReturningFromConfirmationPage is true), prioritize using firstParticipant?.reportID over transaction?.reportID when calculating chatReportID for navigation
• This ensures the route's reportID matches what the confirmation page expects (transaction.participants[0].reportID), allowing the validation check to pass
• thus we need to change the chatReportID to be:

                const participantReportID = firstParticipant?.reportID;
                const iouReportID = participantReportID ?? transaction?.reportID;
                const selectedReport = iouReportID ? getReportOrDraftReport(iouReportID) : null;
                const navigationIOUType = isSelfDM(selectedReport) ? CONST.IOU.TYPE.TRACK : CONST.IOU.TYPE.SUBMIT;
                const chatReportID = participantReportID ?? selectedReport?.chatReportID ?? iouReportID;

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

NA

What alternative solutions did you explore? (Optional)

NA

[abzokhattab]

Can reproduce it as well.

[mananjadhav]

I can reproduce it consistently. I'd like to take this as a C+, as I reported and can reliably reproduce it.

[Krishna2323]

@mananjadhav I’ve already volunteered for the C+ here: #76445 (comment). Would you mind if I take this one?

[melvin-bot]

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

[strepanier03]

Shoot, I can't test iOS.