[Xero] Import page error message RBR isn't always displayed

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

---

Issue found when validating #41917 Version Number: 1.4.74-1 Reproducible in staging?: yes Reproducible in production?: new feature 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:

Preconditions:

1. Log in with an expensifail account
2. Have a Collect workspace with accounting enabled and Xero connected.
3. Simulate failing network requests is tuned on in the troubleshoot tab.
4. Navigate to workspace settings - Accounting - Import turn on or off "Tracking categories" "Re-bill customers" and "Taxes"

   Expected Result:

   RBR should always show.

   Actual Result:

   Xero Import page error message RBR isn't always displayed. I was only able to get the RBR on iOS but only for one of the three import options.

   Workaround:

   unknown

   Platforms:

   Which of our officially supported platforms is this issue occurring on?

   • [x] Android: Native
   • [ ] Android: mWeb Chrome
   • [x] iOS: Native
   • [x] iOS: mWeb Safari
   • [x] MacOS: Chrome / Safari
   • [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/Expensify/App/assets/38435837/4e0c3310-0e31-4db6-8939-1d5477ff1f0e

View all open jobs on GitHub

[melvin-bot[bot]]

Triggered auto assignment to @muttmuure (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.

[melvin-bot[bot]]

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

[melvin-bot[bot]]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open Staging deploy checklist to see the list of PRs included in this release, then work quickly on the following:

1. If you find which PR caused the issue/bug, you can reassign it to the person responsible for it.
   • If the author is OOO or won’t get online before the daily deploy is due, you are responsible for finding the best fix/path forward. Don’t hesitate to ask for help!
2. Try to reproduce the issue, if the bug is on production, remove the DeployBlocker label but stay assigned to fix it (or find out which PR broke it to get help from the author).
   • You can adjust the urgency of the issue to better represent the gravity of the bug.
   • If the issue is super low priority, feel free to un-assign yourself.
   • Be careful with PHP warnings, sometimes it is more complex than just adding a null coalescing operator as they might be uncovering some bigger bug.
   • If it was a one-off issue that requires no action (for example, Bedrock was down or it is a duplicated issue), you can close it.

Remember rule #2: Never un-assign yourself from a real DeployBlocker unless you are 100% sure someone else is assigned and will take care of it.

[github-actions[bot]]

:wave: 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.

[m-natarajan]

@Julesssss FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[Julesssss]

My initial thought is that this shouldn't block the deploy:

• It is a new feature, which wasn't working prior to the changes being merged
• It is an edge case that is unlikely to be triggered by any user

[muttmuure]

agreed

[Julesssss]

Removing the label. This was only. just implemented and isn't a regression

[trjExpensify]

Yep, Xero is behind a beta as well. 👍

[SzymczakJ]

I suppose this is not a bug and it is caused by the way "Simulate failing network requests" tool is working. When having this "failing requests" on, the app is retrying requests multiple times in random time intervals. That means we need to wait for every request to give us an error message(and sometimes it can last few minutes), so probably RBR indicator isn't always displaying because the user hasn't waited enough time. @m-natarajan can you test it once more? Turn on or off "Tracking categories" "Re-bill customers" and "Taxes" and wait for about 3-5 minutes, then all RBR indicators should be there. To support my theory I post picture of import page all in RBR indicators, it took me 5 minutes for all of them to appear 😃

[Julesssss]

Hmm, yeah, it isn't clear whether simulate failing requests are the bug or just a way to reproduce... if the the former we can close

[trjExpensify]

If we want @m-natarajan / Applause to retest, let's make sure the label gets added.

[muttmuure]

Waiiting for applause to retest

[melvin-bot[bot]]

@Julesssss, @muttmuure Huh... This is 4 days overdue. Who can take care of this?

[Julesssss]

Same as above

[Julesssss]

Awaiting the weekly retest

[melvin-bot[bot]]

@Julesssss @muttmuure this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!