Web - Workspace settings - Unable to open Accounting page, loading spinner and error in console

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.9-1
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause - Internal Team

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Login with any account
3. Go to Account settings -> Workspace
4. Open any WS or create a new one
5. More future -> Enable Accounting
6. Open the Accounting page

Expected Result:

Accounting page opens without any error

Actual Result:

Unable to open Accounting page, loading spinner and error in console

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

Add any screenshot/video evidence

Bug6546719_1721344522559.bandicam_2024-07-19_02-06-00-497.mp4

View all open jobs on GitHub

[melvin-bot]

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

[lanitochka17]

@alexpensify 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

[lanitochka17]

We think that this bug might be related to #wave-collect - Release 1

[tsa321]

Back end issue, the returned onyxData from OpenPolicyAccountingPage:

The error is from here:

App/src/libs/Middleware/HandleUnusedOptimisticID.ts

Line 21 in 808b7c8

responseOnyxData.forEach((onyxData) => {

[alexpensify]

@thienlnam - Since this is a backend issue, should it be internal or external? Thanks for the update!

[aldo-expensify]

Back end issue, the returned onyxData from OpenPolicyAccountingPage:

I think that is expected from the backend response, in the testing steps we don't get to the point where we connect to QBO (or any other integrations) so it is expected that connections is null

[aldo-expensify]

This is not necessarily a backend problem, needs to be investigated first

[aldo-expensify]

Doesn't seem to be a deploy blocker, I can reproduce in production:

[aldo-expensify]

Maybe it is some change in Auth? since it is happening in staging and production?

[tsa321]

@aldo-expensify there is onyxData inside onyxData. I think the structure of the response is incorrect.

[aldo-expensify]

ooh, that is a good catch, thanks, I'll look into that

[aldo-expensify]

PR up: https://github.com/Expensify/Web-Expensify/pull/42819

[alexpensify]

Thanks for the swift action @aldo-expensify!

[alexpensify]

Keeping this one closed, no action is required on the BZ side and there is no payment. Everything was handled internally.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[alexpensify]

@aldo-expensify - is this notice an error or do we need to come up with a plan to address it? Thanks!

[aldo-expensify]

I believe this is being addressed in the GH issue where this was mentioned.

[alexpensify]

Thanks!