QueryDispatcher/Request.js refactor

[boltzmannsBane]

In this PR:

• Refactored QueryDispatcher/Request.js using async/await syntax
• Fixed error handling & formatting
• Made methods more semantically precise - methods only do what their method name suggests they are

[aws-amplify-eu-west-1]

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-5028.d25kd40decjpue.amplifyapp.com

[aleksandrakorolova]

1. Can reproduce issue from the task:

• URL for Men category
• Category Description for Tech category
• Products from Women category
  

2.Error fetching messages don't appear BUT Error message 'Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'message')' appears in the console

[aleksandrakorolova]

1. Still can reproduce different cases:

• URL and category description are displayed for category X but products are displayed for category Y
  
• URL and products are displayed for category X but category description for category Y
  
• URL is displayed for category X but category description and products for category Y
  

2. Fixed

[boltzmannsBane]

Relevant for #3731 and #3088:
Those issues are a byproduct of our caching strategy.
I initially planned to cancel a request if a newer request was dispatched before the previous one completes. The problem is that the cache is... to fast. Getting a response from the cache only takes 2-3ms, which is way faster than a human is physically able to click on a new link to dispatch a new request and cancel an older one.
This becomes problematic when the service worker, which sends requests to an actual server, on slow 3g takes anywhere from 200ms-6s to complete a request. A user can queue multiple uncancellable requests like that, and they all will resolve and attempt to update the app state, which leads to the behavior described in the aforementioned issues.

This PR won't solve the issues but it still has a lot of good code, reactors, adjustments, etc, so I believe we could still try to merge it.
How to test: this PR doesn't add anything new behavior-wise. As long as homepage/pdp/plp/cart/checkout work as intended, it's safe to merge.

[Ylmzef]

I'm still facing with this issue in 5.3.3

[sliceem88]

Getting error on search with this fix:
code: "410" error: true message: "Query hash is unknown"

Rolled back to 5.3.3

[boltzmannsBane]

@Ylmzef this PR won't fix the issues, refer to the earlier comment

@sliceem88 Is the search result broken as well? If it's just the log, you're most probably seeing it because of better error handling and the cause of the error exists in the older versions too. There are also a few edge cases that cause the search to fail that are unrelated to this PR.

[Ylmzef]

Getting error on search with this fix: code: "410" error: true message: "Query hash is unknown"

Rolled back to 5.3.3

Same here

[sliceem88]

@Ylmzef this PR won't fix the issues, refer to the earlier comment

@sliceem88 Is the search result broken as well? If it's just the log, you're most probably seeing it because of better error handling and the cause of the error exists in the older versions too. There are also a few edge cases that cause the search to fail that are unrelated to this PR.

Yes, search doesn't work. Also some random PDP.

Any reason why rolled back worked ?

[Ylmzef]

Yes, I rolled back to 5.3.3 and it's working fine again.

[Ylmzef]

is there any progress yet? Our website not available to customers for a long time due this issue.
Maybe can you release a patch for this issue? It’s not a simple problem for live shops.

[boltzmannsBane]

@Ylmzef the fix can be found here.