Joakim Olsson
Joakim Olsson
Ok, perhaps one more nugget of information. Each query works on it's own as long as my two subscriptions have not already ran. If I run my three queries from...
It's my subscription which return the Company-type that is causing the problem.
Which also introduces a third subgraph which extend the Company-type. I'll try to modify my current test to also plan the subscription first.
Still unable to reproduce this in a test 🙁 It's losing the Company.__typename in the secondary run for some reason.
If I add the Company.name to the queries it magically starts to work again. So the problem only exists if I select the key, __typename as well as whatever the...
Adding Company.name would then of course introduce an extra call to the company subgraph which would not really be needed since both id and __typename should be available from any...
Here is a 15k lines log with loads of debug-data. To me it looks like it should find Company.__typename in the first planner but still it claims that it's missing....
Hmmm, on the other hand it seems to want to get __typename from another DS (12485775574321252452) which is not part of any of the two planners (5424679272531918615 and 6927017134761466251). In...
If I exclude __typename like this it works: https://github.com/wundergraph/graphql-go-tools/pull/847 Not sure what I break by doing it though.
No worries at all. That one works perfectly! 🎉 🚀