-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
__typename field missing in suspense queries #256
Comments
That's very curious, thank you for the report. I can see the |
Could you please try this release and report back if it fixes your issue? npm i @apollo/experimental-nextjs-app-support@0.0.0-commit-4875530 It's the end of my day now, but I'll pick this back up tomorrow and your feedback would be very valuable to me! |
Looks like it's fixed. |
One thing that has come up by investigating that I wanted to run by you: This code path has not changed since 0.8.0. What has changed is when it is executed: In 0.8.0 it would be executed if:
In 0.9.0 it would be executed it:
So, this should only happen in "fallback" situations. Are you seeing this all the time in your code? If yes, could you please give an example on how you use the library, or maybe even a reproduction of this happening? |
@phryneas – it happens every time with version 0.9.0 Deps version
log from server console
graphql operation (separated in graphql file, generated typedNode via gql codegen)
gql codegen config
response in browser Apollo devtools field inmemory cache config
apollo wrapper
|
@phryneas Maybe could be problem with my cache config and
I use the node interface and rely on the fact that objects can be identified just by ID (Global object identification standard, relay like) |
Could you set the log level to
Also, which hooks are you using in your components? |
@phryneas
streaming connection closed before server query could be fully transported, rerunning:
|
This should be an exception, not the norm every time you render a component or page - it should only happen if you use |
Nope, I use
|
It looks like your Do you have any possible explanation for this, e.g. components triggering an error and triggering an error boundary during SSR? (Or is |
@phryneas |
And with logging enabled, do you get that same
in 0.8.0? |
@phryneas There is no any verbose logs in version 0.8.0 |
Nothing? That seems wrong, even in a 100% success, it should log something. |
Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo Client usage and allow us to serve you better. |
This should not have autoclosed, I'm just getting #257 released as 0.9.1 on the side, because that's definitely a necessary bugfix regardless if we find something on top of it here :) |
Hm.
|
Problem is: I'd love to help you further with this, but it's the end of my day again and I'll be away for the next 5 days. As for now, I've published the It would be great if in the meantime you could provide me with some kind of reproduction for that early-closing stream that you are seeing, as I can't reproduce that here in any of our integration tests. I'd love to dig deeper into this as soon as I'm back. |
@phryneas My mistake, I'm sorry, but the hotfix
So I set the field |
Great that you found it! I just got another idea that might add a puzzle piece here, so I'm writing from my vacation account 😅 Before 0.9.0, you needed to use the hooks imported from Since 0.9.0, you just need to create the So my guess here why you don't see any logs when going back to 0.8.0 would be: did you maybe import the hooks from the (back then) wrong package? |
In version 0.8.0:
__typename
in every type by defaultIn version 0.9.0:
__typename
missing by default, it's included only when specific type has explicit__typename
field to resolve in operationeven with cache config option
addTypename: true
.The text was updated successfully, but these errors were encountered: