Regression in BatchHttpLink with v3.7.0: queries hang and are not issued on network requests

[vieira]

Intended outcome:
All pending queries should be dispatched to the network.

Actual outcome:
Queries are not dispatched to the network, they just hang, loading returned from useQuery returns true indefinitely. This issue first appeared in v3.6.x (#9690) and was fixed in v3.6.7. The issue does NOT occur in v3.6.9 and v3.6.10 but occurs in v3.7.0.

Not sure if the regression was introduced when backporting (#9807) or by some other change.

How to reproduce the issue:
Using BatchHttpLink as a terminating link and having a page with a buch of queries should exhibit the issue.

Versions
v3.7.0

(Note: this has previously affected v3.6.x prior to v3.6.7. Can confirm it does not occur with v3.6.9 and v3.6.10)

[oddeirik]

Seeing the same thing as vieira: using the BatchHTTPLink in 3.7.0 or 3.7.1 makes some of the queries never execute and they are left in a loading state.

When reverting to 3.6.9 (previously used version), or removing the usage of the BatchHTTPLink, it works again.

[EvHaus]

We just ran into the same issue ourselves. A few observations:

• It seems to only occur with many parallel requests happening. With a default batch size of 10 we would see certain requests simply fail to get called. It's like Apollo doesn't fire them at all. Setting the batch size to something smaller (like 3) would ensure all requests go through.
• The issue was present on 3.7.1 in addition to 3.7.0. Rolling back to 3.6.10 made the issue go away.

[vpotapchuk]

We also faced the issue. After some investigation we found out that this happens when we don't send the same context while we do Promise.all on two queries. In our case we send context in one case and not the other, but it always happens unless two contexts are the same (same meaning the JSON.stringify would give the same result, not meaning it's the same reference).

We see that one query is sent via the network, but not the other. Moreover, the one that is sent is always the LAST one in the Promise.all array.

We are not using useQuery in this specific case since the queries are run during SSR.

Very easy to reproduce, I think this minimal repro would be enough if only the BatchHttpLink were used here:
https://codesandbox.io/s/sharp-sound-1d0ojj?file=/src/App.js:618-914

If somebody knows how to modify that code to use BatchHttpLink, would be great

It's still present in 3.7.3 and 3.8.0-alpha.3

[vpotapchuk]

@bignimbus will my extra info above speed up resolving this?

[bignimbus]

Hi @vpotapchuk 👋🏻 the linked PR #10408 is almost ready to ship. I appreciate the link but since it doesn't demonstrate the problem as-is we'll need to modify it in order to do a manual test of the PR, which is fine. Are you able to pull the branch in the PR and test in your app locally?

[bignimbus]

Hi all, the fix should go out in the next patch (3.7.6). If you get a chance to validate against our main branch in the meantime, that would be great!

[modi98]

Hey, I just confirmed on your latest changes, this solved the issue, thanks

[vpotapchuk]

Hey, I also just tested the 3.7.7, everything works correctly for us now! Great job!

@bignimbus Sorry for not answering earlier, I realized I have some problems with github notifications...

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.