v3.0.9 Creating node manifest warnings

[dw-srohrlack]

Since v3.0.9 the plugin creates a lot of notices and warnings when running "develop". It looks like these messages are displayed for each datocms record which makes the terminal output basically unreadable when having a lot of records.

info DatoCMS: Creating node manifest with id 44532902-2021-11-09T14:06:25.002+01:00

warn Plugin gatsby-source-datocms called unstable_createNodeManifest() for node id
"DatoCmsPage-44532902-en" with a manifest id of "44532902-2021-11-09T14:06:25.002+01:00" but Gatsby
 couldn't find a page for this node.
      If you want a manifest to be created for this node (for previews or other purposes), ensure
that a page was created (and that a ownerNodeId is added to createPage() if you're not using the
Filesystem Route API).

[matjack1]

@DanielSLew we can remove the info log as it's the source plugin adding that, but what about the warn? Looks like coming from Gatsby core, right? Can you suggest any fix for that?

[matjack1]

meanwhile @dw-srohrlack I've just released v3.0.10 which removes the info logging

[DanielSLew]

@matjack1 you're right this is very messy in terms of CLI output. The info logging in the source plugin is very useful for debugging so maybe we can just hide that behind a verbose or a debugging env var rather than removing it completely. I'm going to look into how to reduce the noise in gatsby for the warning though.

[lofgrenfredrik]

We are having the same "problem" with manifest warnings. Most of them we could solve by passing ownerNodeId to createPage, but for the records/blocks that are not used in createPage the warning still shows up in the logs.

[erasmussenBHTP]

I'm attempting to upgrade to Gatsby V4, but I'm getting an error that seems related to these node manifest warnings. The error stops the entire build process. I've been trying to delete records out of a development environment to see if I can isolate the cause of the issue. It appears to be related to models that store data that aren't necessarily associated with a page. I'm even getting the warnings for the Schema Migration model that gets added by the CLI for migrations, and that also causes the error. It's not like it's every schema migration - I have about 10 of them and only 2 cause the error. Deleting them fixes it, but obviously that messes up future migrations. I'm not querying the schema migration model anywhere in my project.

I'm currently on 3.0.10 of the gatsby-source-datocms plugin and have not tried any of the other 3.0.# versions (last installed was 2.6.16).

Missing onError handler for invocation 'extracting-queries', error was 'Error: ENOENT: no such file or directory, open 'C:\development\marketing-site\public\__node-manifests\gatsby-source-datocms\72739177-2021-11-11T13:48:21.917-06:00.json''. Stacktrace was 'Error: ENOENT: no such file or directory, open 'C:\development\marketing-site\public\__node-manifests\gatsby-source-datocms\72739177-2021-11-11T13:48:21.917-06:00.json''

Edit - After looking at this more, all of the records that are causing issues were created within the last 48 hours and are considered recently updated based on this code. Is there anything I need to do differently compared to the previous version of gatsby/datocms? I didn't see anything that stood out in the gatsby migration guide.

[veryspry]

I'm attempting to upgrade to Gatsby V4, but I'm getting an error that seems related to these node manifest warnings. The error stops the entire build process. I've been trying to delete records out of a development environment to see if I can isolate the cause of the issue. It appears to be related to models that store data that aren't necessarily associated with a page. I'm even getting the warnings for the Schema Migration model that gets added by the CLI for migrations, and that also causes the error. It's not like it's every schema migration - I have about 10 of them and only 2 cause the error. Deleting them fixes it, but obviously that messes up future migrations. I'm not querying the schema migration model anywhere in my project.

I'm currently on 3.0.10 of the gatsby-source-datocms plugin and have not tried any of the other 3.0.# versions (last installed was 2.6.16).

Missing onError handler for invocation 'extracting-queries', error was 'Error: ENOENT: no such file or directory, open 'C:\development\marketing-site\public\__node-manifests\gatsby-source-datocms\72739177-2021-11-11T13:48:21.917-06:00.json''. Stacktrace was 'Error: ENOENT: no such file or directory, open 'C:\development\marketing-site\public\__node-manifests\gatsby-source-datocms\72739177-2021-11-11T13:48:21.917-06:00.json''

Edit - After looking at this more, all of the records that are causing issues were created within the last 48 hours and are considered recently updated based on this code. Is there anything I need to do differently compared to the previous version of gatsby/datocms? I didn't see anything that stood out in the gatsby migration guide.

Hey @erasmussenBHTP! Node manifest files (the type of file pointed at by the error you are seeing) are used by a new preview feature called "Content Sync". Sometimes these files are created with names that include invalid character on Windows. These files are not really needed during local development of a Gatsby site and we recently merged a fix that will replace invalid chars if the dev server is running on Windows in this Gatsby PR

It looks like the next release is schedule for November 16th but we might try and get a release out sooner so that this issue can be resolved.

[erasmussenBHTP]

@veryspry thanks for the update. I installed 4.2.0-alpha-node-manifest-windows-escape.67 and I was able to run without any issues. 4.2.0-next.3 did not work, but I'm assuming that just didn't contain the change. I'm still in a pre-production version of my website so there's no rush needed on my end.

[veryspry]

@erasmussenBHTP Great! That was an alpha release I made for testing, but I'm glad you found it. I should have suggested that earlier. :)

Please note though that the alpha release you are using has not been thoroughly tested outside of this Windows specific path character issue, so there is a small chance that it would behave strangely. But, it's most likely going to be on par with 4.2.0

[Chayemor]

I'm currently experiencing something similar, with hundreds of warnings such as:

Plugin gatsby-source-datocms called unstable_createNodeManifest() for node id "BlockNameHere8790200-de-DE" with a manifest id of
"8790200-2020-03-18T09:55:44.840+01:00" but Gatsby didn't find a ownerNodeId for the page at /de/page-slug-here/
Using the first page where this node is queried.

Looking at the previous messages, the following scenarios were tried but none of them fixed the warnings:

• Adding ownerNodeId
• Upgrading the package to v4

Because the warnings give off the id of the block that is causing the problem, I searched it in GraphQL and ended up finding the page that it belongs to. So I'm not sure why the warning is happening, if the block is there for that page, and that locale.

Has anyone figured out how to turn off the warnings?

[veryspry]

@Chayemor thanks for the report!

I'm currently experiencing something similar, with hundreds of warnings such as:

I dont remember which version this was released under, but the plugin does currently have code to limit that warning to only print to stdout one time:

https://github.com/datocms/gatsby-source-datocms/blob/master/src/utils.js#L96-L101

Because the warnings give off the id of the block that is causing the problem, I searched it in GraphQL and ended up finding the page that it belongs to. So I'm not sure why the warning is happening, if the block is there for that page, and that locale.

Based on the node to page mappings hierarchy that we use to match nodes to pages, it seems like you may have found a bug or an edge case that we should account for.

unstable_createNodeManifest - which is currently defined here in the Gatsby code base - has some logic to attempt to match a node to a page and it should be detecting that page that you found that is associated with your node in question.

It sounds like this might be specific to your setup and could be quite tricky to debug. Can you provide a minimal reproduction setup for this including a DatoCMS instance that I could source and inspect? This will make it easier for us to scope / prioritize the issue and find a fix for it :slightly_smiling_face: