-
-
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
Bug: Infinite looping GraphQL requests, reported from faustjs #558
Comments
Looking at the repo containing the bug It seems that the code triggers the loop originates from this component: It then triggers something and goes back to the same susbscibe-resolve section here: gqty/packages/react/src/common.ts Lines 417 to 447 in 237fb26
The stack trace loops again and again with this component. I suspect it's something to do the way it renders the React Component again and again. |
The code also seems to loop around this block: gqty/packages/react/src/common.ts Lines 106 to 142 in 237fb26
|
Looking at the code here it looks like it falls into the troublesome case of data-selections-conditionals: https://gqty.dev/docs/react/troubleshooting#data-selections--conditionals The
The
For the
For the The @PabloSzx is there a recommended way to deal with switch statements of that kind? What do you think? |
I also managed to replicated it more consistently. It looks like in the switch statement here: Any component that shares the same properties with a different component in a switch statement picks up their properties and tries to request them under a different Query Fragment. For example: The components
Now before the page finishes loading you click on the
However the
Notice that both
This means that somehow GQty uses the wrong On the other hand you can also check the I hope that helps. |
@theodesp Having the same issue here: |
@PabloSzx is there a way to globally disable cache for GQty to bypass this issue? |
Copying issue reported in wpengine/faustjs#723 (comment) thank you @mediashane
I could confirm this bug, and doesn't seem to be a bug on server side, the weirdest thing is that this bug doesn't happen on development mode, only after building Next.js and starting on production mode, this makes debugging way slower since making changes on node_modules takes a whole build start
The text was updated successfully, but these errors were encountered: