-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Direct-ID lookup for nodes in graphql fails in some instances #22004
Comments
Can you clarify the "random" part? I mean - if you run this query twice in GraphiQL - do you get different results? Or maybe some action during the development session changes the behavior? |
Sorry, by random I meant that I couldn’t find any reason why this one is the one affected. It is always the same node, and it always fails |
Is it possible to get access to your project so that we could take a look locally? I'll post an email in the next message (will delete later) |
I've looked into it and I don't think we're able to provide access to the project sorry. It's in a monorepo with a few other intertwined projects, as well as it uses a few libraries from private NPM repos. |
Hi @me4502 I understand but the problem is that it is nearly impossible to debug this without reproduction. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it. Thanks for using Gatsby! 💜 |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Hey again! It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it. Thanks again for being part of the Gatsby community! 💪💜 |
So we've had this occur again in a way that cannot be worked around. Using contentful, rich text fields are a separate node, accessed through I understand this is almost impossible to debug without a minimal reproduction, however I have not been able to create one reliably. The best I can do is using the exact same data so that the node store is in the same state. However this is still not minimal and is very intertwined with systems that can't easily be shared. I'm happy to debug and solve this, my main reason for asking again now is to work out if anyone on the Gatsby team has any ideas about what areas of the codebase could cause something like this. I've been looking into it for a few days and haven't been able to find a concrete cause. |
@me4502 There are some known issues with Contentful's rich text feature, documented below, which might give some direction! |
@benrobertsonio Those issues are referring to the partial sync the API does on update, we’re using the option to force a full sync to get around that issue. This issue is outside of the Contentful plugin from what I can tell. The data is all there correctly in Gatsby’s node store, it just cannot be queried by ID from graphql. |
I am curious if it is the same with contentfulBlogPost(id: { in: ["your-mysterious-id"] }) {
id
} (at the moment this bypasses id indexes). Also worth trying And just to clarify - you can't reproduce it on the same contentful space but with some simple starter (using GraphiQL to check the results)? |
Using I haven't specifically tested with just the contentful space, as the issue doesn't only occur with contentful data. It happens to pretty much any type of node, just a very small percentage of them. I will do a test with just that shortly. |
I just confirmed that the same issue occurs with a fresh |
Sounds like a repro? Can you share it? As far as I understand we need a temporary content delivery token only to see it? |
Thanks, I've just emailed the key and other required info to the email you posted earlier |
Surprisingly, I can't reproduce it locally. Tried this query: {
allContentfulBlogPost(filter:{slug:{eq:"download-youtube-videos"}, node_locale:{eq:"en-US"}}) {
nodes {
id
contentful_id
title
}
}
contentfulBlogPost(id:{eq:"cd0ea374-9b02-5fdd-8294-08fb642c741d"}) {
id
title
}
} And got the expected result: {
"data": {
"allContentfulBlogPost": {
"nodes": [
{
"id": "cd0ea374-9b02-5fdd-8294-08fb642c741d",
"contentful_id": "blog-download-youtube-videos",
"title": "How to Download YouTube Videos, Step-by-Step"
}
]
},
"contentfulBlogPost": {
"id": "cd0ea374-9b02-5fdd-8294-08fb642c741d",
"title": "How to Download YouTube Videos, Step-by-Step"
}
}
} The screenshot: Maybe it is some other node now? Can you share your steps? |
I'm on my phone so don't have the exact query, but I basically queried for This gave me a list of all the ContentfulBlogPost nodes that had a content___NODE that was unable to be resolved |
I see such nodes (where They are created and then deleted for some reason (all during But I do repro cases with |
Did some digging. A rich text node is a child of a blog post node. And we have a weird sequence of calls in contentful plugin:
So the same blog post node is created twice. The problem though that when we re-create existing node Gatsby deletes all of its children (assuming they will be re-created too). But contentful plugin never re-creates them hence we get the blog post without text node. Still digging why contentful calls |
Ok, it looks like you have identical
The Ideally, ids should be unique for a single contentful space. But contentful source plugin could have namespaced it with content type to avoid collisions like this. A PR is welcome - it shouldn't be too complex! Basically add gatsby/packages/gatsby-source-contentful/src/normalize.js Lines 100 to 103 in c350f59
|
Ah, thanks - I’ll submit a PR on Monday. When testing this new issue I used getNode to see if it still existed and it retuned a result, which a conflicting ID would explain. For the original issue, using just the Contentful data made it return different broken pages so I’ll try finding which ones are affected with just that data, thanks |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Hiya! This issue has gone quiet. Spooky quiet. 👻 We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here. Thanks for being a part of the Gatsby community! 💪💜 |
Hey again! It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it. Thanks again for being part of the Gatsby community! 💪💜 |
Description
When querying a single node by a direct-ID lookup, the query sometimes returns null. Querying for the whole list, and filtering by something such as slug finds the document fine, with the same ID.
Thanks to @DSchau for helping me debug this.
I had a feeling it was related to #20609, but after testing on a version from before that change (2.18.22), the issue still occurs.
Steps to reproduce
I have no idea how to reliably reproduce this sorry. It has randomly occurred on my project. It appears to just be the one node, on a page with >10k pages (so therefore a lot of nodes are in the db)
This query on the site shows it in a simple way, however.
Expected result
The
contentfulBlogPost
query should be able to find a node, as the above query has proven it exists and provided an ID.Actual result
A direct-ID lookup for this object does not work. Looking up by other things, such as contentful_id, do work.
Environment
The text was updated successfully, but these errors were encountered: