fix executing standby queries in ssr

[atarek12]

close #9336
close #9108

I tried this and all is working as expected. The issue was the promise is not resolved and keep loading forever whenever the fetch policy was standby.

[apollo-cla]

@atarek12: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/

[atarek12]

@brainkim @benjamn you can address this example to find the issue

[atarek12]

I have added tests for this case

[atarek12]

@brainkim @benjamn any updates?

[WaveDashShine]

is this merge request still being looked at?
I'm running into issue #9108
Is there a workaround for useLazyQuery in the meantime?

[atarek12]

is this merge request still being looked at? I'm running into issue #9108 Is there a workaround for useLazyQuery in the meantime?

The current workaround is to set ssr: false in the query options

[atarek12]

I have reverted the main branch changes to get all tests green, but here are some failed tests due to outdated docs.

[atarek12]

• have pulled the new apollo client version
• adding a small fix when using useQuery hook with fetchPolicy = "standby" in SSR mode
• adding test cases for that

[atarek12]

@jpvajda any updates related to this PR?

[jpvajda]

@atarek12 Apologies for delay here! I'm going to tag @benjamn on the review. We've done a decent amount of work around useQuery so I want to ensure this PR won't create any conflicts before merging.

[atarek12]

I have posted a reproduction case for that in the issue and I am gonna repost it here too

here is my reproduction case, clone this repo and run yarn and yarn dev

[baygeldin]

Thanks for this PR, it helped a lot in understanding why the getDataFromTree method was getting stuck all the time for no reason. There was not a single query in the codebase that used the standby fetch policy, and yet it was stuck resolving promises for queries that had fetchPolicy: "standby" set somehow, so I figured it was added automatically somewhere. I did some digging and sure enough, if a query uses skip option it sets fetch policy to standby by default. And it does it in such a way that this fix doesn't actually work 😢

So, instead I've applied the following patch (using pnpm patch command, but one could use patch-package as well):

diff --git a/react/ssr/ssr.cjs b/react/ssr/ssr.cjs
index 1241a6767609da0d1ef224b8f9f2ef2cec35147c..ace8f0adcb5dabfd982cef09507119a79d4edf5b 100644
--- a/react/ssr/ssr.cjs
+++ b/react/ssr/ssr.cjs
@@ -61,6 +61,7 @@ var RenderPromises = (function () {
         return finish ? finish() : null;
     };
     RenderPromises.prototype.addObservableQueryPromise = function (obsQuery) {
+        if (obsQuery.options.fetchPolicy == 'standby') return null
         return this.addQueryPromise({
             getOptions: function () { return obsQuery.options; },
             fetchData: function () { return new Promise(function (resolve) {

Make sure to patch the right file (react/ssr/ssr.cjs, not react/hooks/useQuery.js). Server-side bundles use different modules than those on the client side.

[baygeldin]

Also, semantically speaking I don't think that force skipping SSR for standby queries makes sense. These queries still need to make a network request during SSR and populate the cache (it's not cache-only after all). The problem is that RenderPromises relies on the ObservableQuery to notify it when data is fetched, but the whole point of standby queries is that they don't notify anything so that they don't trigger re-render of components that use them.

Currently, the workaround is to treat any query with skip option set carefully and don't use the standby fetch policy when using SSR. And just in case apply the aforementioned patch so that your server doesn't hang resolving promises that ain't gonna resolve anyway.

So, all in all this is a really nasty bug and I don't think a simple fix would work here because the issue runs deeper. Although maybe @benjamn could shed some light on a possible solution since it's related to SSR 🙏

[jpvajda]

@jerelmiller @bignimbus - This PR might be relevant to some of the work we are doing to offer better SSR support, could you both take a look when you have a free moment?