gatsby: Hot reloading error: "path" argument must be of type string

Hot reloading in gatsby develop gives this error in my project. Hot reloading sometimes works despite the error (as in, I see the error in the console window where I ran gatsby develop, but the website in browser appears to hot reload and work just fine). This error appeared after I updated some (mainly Gatsby) npm dependencies. Stack trace is giving me no ideas on how to debug this. Is it a Gatsby bug?

Note that this error only comes up on hot reload. So I can run gatsby develop just fine as long as I don’t make any changes to any files. I can also build just fine.

[ { TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined
      at assertPath (path.js:39:11)
      at Object.resolve (path.js:1085:7)
      at findLinkedFileNode (/.../node_modules/gatsby/dist/schema/resolvers.js:208:47)
      at resolveValue (/.../node_modules/gatsby/dist/schema/resolvers.js:223:108)
      at /.../node_modules/gatsby/dist/schema/resolvers.js:220:10
      at process._tickCallback (internal/process/next_tick.js:68:7)
    message:
     'The "path" argument must be of type string. Received type undefined',
    locations: [ [Object] ],
    path:
     [ 'allMarkdownRemark', 'edges', 0, 'node', 'frontmatter', 'cover' ] } ]

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 8
  • Comments: 17 (11 by maintainers)

Commits related to this issue

Most upvoted comments

A fix by @sdobz totally works as a dirty temporary solution. The error stops breaking gatsby, and you just need to hit refresh to see your changes (not ideal, but whatever, it’s better then restarting gatsby every time I save a file)

This is still a pressing issue though, rendering gatsby develop unusable for, well, development. It would be really cool if some one from the core team addressed it soon 😎

Just wanted to note that this issue still exists in gatsby 2.18.5.

I’m seeing this behaviour as well and am here to test if/when needed. 😃

Ok, update: Comment above is correct - just more details on why this happens: In our node tracking code, we check if node is being tracked by using “tracked nodes” list that contain node IDs: https://github.com/gatsbyjs/gatsby/blob/95e908e3605eb2a0a240801f6c8ac5677ba9d6d7/packages/gatsby/src/schema/node-model.js#L336-L339

So when node is being updated (preserving its ID), we don’t track new node.

This problem is not visible in page/static queries because we reset the entire “Node model” instance (which removes/resets list of tracked nodes and bunch of other things related to Materialization) in https://github.com/gatsbyjs/gatsby/blob/95e908e3605eb2a0a240801f6c8ac5677ba9d6d7/packages/gatsby/src/query/index.js#L349-L362 (graphqlRunner is object that have instance of "Node model, so resetting runner also resets used “Node model”)

We could do the same for graphql function being used in gatsby-node APIs (including createPages) - https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/bootstrap/graphql-runner.js (I just did dirty test and it seems to fix the issue).

But this raises question - we have multiple unrelated “Node model” instances which potentially cause duplicate work that those “Node model” instances do - maybe there should be single “Node model” instance that will reset itself when needed so graphql runners don’t need to care about this detail (and also this could avoid potential duplicate work) - this is tricky issue and I think we should first fix it by resetting graphql runner used in gatsby-node APIs (similar to development query runner queue)

/cc @freiksenet

@pieh could you share the dirty fix? I’m wallowing around in code I don’t understand looking for a place to do additional node tracking when a node is hot reloaded. Is this the right track? What files should I look in to get a handle on the hot reload lifecycle?

I have this behaviour and it’s becoming a bit frustrating. Mine it’s related to my “hero” image inside markdown files (not mdx):

By the way, just few days ago the error was more detailed, since it was related to “hero”. It said something like: The "hero" argument must be of type object. Received type undefined

This is the error now:

 ERROR #11321  PLUGIN

"gatsby-node.js" threw an error while running the createPages lifecycle:

The "path" argument must be of type string. Received type undefined

GraphQL request:9:15
 8 |   title
 9 |   hero {
   |               ^
10 |           childImageSharp{

failed createPages - 4.121s

this is my graphql query under gatsby-node.js file

{
allMarkdownRemark(sort: {fields: frontmatter___date, order: ASC}) {
    edges {
      node {
        frontmatter {
          imghero
          slug
          title
          hero {
            childImageSharp {
              fluid(maxWidth: 700, quality: 85) {
                src
              }
            }
          }
        }
      }
    }
  }
}

Also I’m here to test if needed

So what I found is that the markdown front matter is getting confused as a ContextualNodeModel. So when you run Path.resolve(args), it is getting the front matter object, which doesn’t have the ‘dir’ attribute. I’m going to throw up a PR for the fix.

I’m interested in looking into this. @pieh , Mind if I poke around and see if I can resolve the issue?