TypeError: Cannot call method 'isDirectory' of null #792

Closed
balupton opened this Issue Jan 29, 2014 · 19 comments

Projects

None yet
Owner

Just checked mixpanel after a few months, and noticed that this error has been getting incurred THOUSANDS of times a day by people... Ever since watchr v2.4.7 December 19, 2013.

DocPad v6.61.0
Node v0.10.21
Platform: win32

Stack:
TypeError: Cannot call method 'isDirectory' of null
  at _Class.changeHandler (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\out\lib\docpad.js:3579:61)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.bubble (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:177:19)
  at _Class.bubble (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:488:36)
  at _Class.EventEmitter.emit (events.js:106:17)
  at watchr.watchChild.next (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:389:26)
  at createWatcher (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:677:9)
  at watch (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:739:16)
  at _Class.watchChild (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:476:46)
  at Task. (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:382:29)
  at ambi (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\ambi\out\lib\ambi.js:23:18)
  at fire (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\taskgroup\out\lib\taskgroup.js:159:23)
  at b (domain.js:183:18)
  at Domain.run (domain.js:123:23)
  at Task.fire (d:\Documents\GitHub\docpad-simpleblog\node_modules\docpad\node_modules\taskgroup\out\lib\taskgroup.js:166:25)
  at processImmediate [as _immediateCallback] (timers.js:330:15)

Now we could just do a undefined check and skip that section of code, but the problem that particular line:

isDirectory = (fileCurrentStat or filePreviousStat).isDirectory()

Should always work, as at least one of those stats should be defined. This need to be looked into.


Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

@balupton balupton added a commit that referenced this issue Feb 21, 2014
@balupton balupton Detection for #792
We need to catch this error somehow.

As it seems this error is suppressed due its location, let’s make it
way more prevalent so we can get this resolved.
d457731
@balupton balupton added a commit that referenced this issue Feb 21, 2014
@balupton balupton v6.63.7. Bugfix.
- v6.63.7 February 21, 2014
	- Fixed IE9 and below not understanding the charset we send
		- Thanks to [Eric Vantillard](https://github.com/evantill) for [issue #801](#801)
	- Better debugging for invalid watch states
		- For more information see [issue #792](#792)
	- Fixed DocPad failing to serve files after the initial generation once the docpad configuration file has been modified
		- Thanks to [Michael Williams](https://github.com/ahdinosaur) for [issue #811](#811)
	- Updated dependencies
1868381
M-Pixel commented Apr 10, 2014

I recently received the following error:

error: An error occured:
Error: DocPad has encountered an invalid state while detecting changes for your
files.
So the DocPad team can fix this right away, please provide any information you c
an to:
https://github.com/bevry/docpad/issues/792
    at _Class.changeHandler (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\
docpad\out\lib\docpad.js:3622:17)
    at _Class.EventEmitter.emit (events.js:106:17)
    at _Class.bubble (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\
node_modules\watchr\out\lib\watchr.js:177:19)
    at _Class.bubble (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\
node_modules\watchr\out\lib\watchr.js:4:61)
    at _Class.watchr.children.(anonymous function).watch.listeners.change (C:\Us
ers\Max\SkyDrive\www\Docpad demo\node_modules\docpad\node_modules\watchr\out\lib
\watchr.js:490:36)
    at _Class.EventEmitter.emit (events.js:106:17)
    at _Class.bubble (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\
node_modules\watchr\out\lib\watchr.js:177:19)
    at _Class.bubble (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\
node_modules\watchr\out\lib\watchr.js:4:61)
    at _Class.watchr.children.(anonymous function).watch.listeners.change (C:\Us
ers\Max\SkyDrive\www\Docpad demo\node_modules\docpad\node_modules\watchr\out\lib
\watchr.js:490:36)
    at _Class.EventEmitter.emit (events.js:106:17)
    at _Class.close (C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\n
ode_modules\watchr\out\lib\watchr.js:432:16)
    at C:\Users\Max\SkyDrive\www\Docpad demo\node_modules\docpad\node_modules\wa
tchr\out\lib\watchr.js:312:20
    at Object.cb [as oncomplete] (fs.js:168:19)
info: Change detected at 18:58:31 create C:\Users\Max\SkyDrive\www\Docpad demo\s
rc\layouts\default.html.eco

I'm not certain that this is the same error balupton describes above, but it instructed me to post at issues/792, which is interesting.

This was triggered by changing a file in /src/layouts from default.html.teacup to default.html.eco. Stopping and starting docpad rendered the file correctly without error.

It was the same problem on my system (KDE linux). I realized that some editors automatically backup file after edited file is modified, not saved yet, just changed in editor, i.e. Kwrite. That event is saving recent changes to backup file, which event triggers watcher. Seems to be the DocPad does not "understand" what happend, throw out this error, and stops file re/generation in out/ directory. Perhaps backup default behavior of used editor should be reconfigured, or try to use other one. I use vim, and no more such error.

Owner

No issues with Brackets, SublimeText 2/3 either.

Sometimes auto-refresh gets crazy though. At HackPrinceton we were trying to get a Freebase tutorial running inside DocPad and the auto-refresh kept generating the page in a loop even after if was deleted and removed from dev-dependencies.

Owner

Not sure if this is true, but it seems this happens for deletions. It's a watchr issue. We just need someone to look into it.

I ran into this while docpad was running and I tried to change default.html.eco to default.html.md.eco

error: An error occured:
Error: DocPad has encountered an invalid state while detecting changes for your files.
So the DocPad team can fix this right away, please provide any information you can to:
https://github.com/bevry/docpad/issues/792
  at _Class.changeHandler (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/out/lib/docpad.js:3622:17)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.bubble (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:177:19)
  at _Class.bubble (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:490:36)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.bubble (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:177:19)
  at _Class.bubble (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:490:36)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.close (/Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:432:16)
  at /Users/aj/Sites/azanebrain.github.io/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:312:20
  at Object.cb [as oncomplete] (fs.js:168:19)
eickler commented Jun 24, 2014

Hi there,

I am getting this when having docpad running and removing a source file of the web site that docpad is watching (in my case through "hg rm ...").

Since I had difficulties with regenerating files on my Mac, I am using "watchOptions: preferredMethods: ['watchFile','watch']" as recommended elsewhere.

Cheers,
André

First time using docpad, but incase it can help.

error: An error occured:
Error: DocPad has encountered an invalid state while detecting changes for your files.
So the DocPad team can fix this right away, please provide any information you can to:
https://github.com/bevry/docpad/issues/792
  at _Class.changeHandler (/home/victor/Projects/site/node_modules/docpad/out/lib/docpad.js:3622:17)
  at _Class.emit (events.js:106:17)
  at _Class.bubble (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:177:19)
  at _Class.bubble (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:490:36)
  at _Class.emit (events.js:106:17)
  at _Class.bubble (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:177:19)
  at _Class.bubble (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:490:36)
  at _Class.emit (events.js:106:17)
  at _Class.close (/home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:432:16)
  at /home/victor/Projects/site/node_modules/docpad/node_modules/watchr/out/lib/watchr.js:312:20
  at Object.cb [as oncomplete] (fs.js:168:19)
Contributor
greduan commented Jun 28, 2014

Thank you @victorhaggqvist. :)

/cc @balupton

I got this error when adding roughly 20 files each with their set of images (5-10).

The message before the error in question says:

info: Waiting on the following files on renderFiles:

It then lists files that failed to render. Eventually it says how many were generated:

info: Generated 182/193 files in 27.36 seconds

As you can see, not all files have been generated.

I decided to see if I could avoid DocPad errors by deleting some of my content for this section of the site—I needed to do that anyway. I deleted a file and got the error specified and directions to come here. So, I'm guessing the error happened in my case because the file is waiting to be rendered, cannot be rendered, and is then deleted.

It seems as though DocPad cannot handle a large amount of files, be it rendering from markdown or copying over from the static directory. I am migrating some content from a PHP-based content management system over to DocPad and I have about 20 child pages each with sets of images. Is this too much for DocPad to handle? Content is being rendered with the markdown plugin, and images are copied into the static directory. Some of the markdown files have HTML in it but from what I understand, markdown can handle that. Also, I do not see any parsing errors like I have before, so I don't think the problem is in the markdown parsing (though I could be mistaken).

Another related issue—I also got caught in an infinite loop during the watching of the images directory, i.e. the /static/images/ directory is watched and keeps logging "Changes detected at ... created /path/to/image" and it would cycle through the entire directly infinitely, finding more changes, and re-creating the images.

I'm running DocPad v6.69.1 and my plugins include cleanurls, eco, highlightjs, ignoreincludes, livereload, marked, partials, sitemap, stylus, thumbnails, uglify

I'm not sure if this is the best place to specify the infinite loop and lack of being able to generate all files with a large amount of images and a few plugins installed, but it could all be related somehow.

If you have large amount of files use raw plugin and put them in src/raw
instead of src/static. Having your files in statick(files) folder is making
docpad index them and this is making you problems.Raw plugin will let you
do what you want.
On Nov 14, 2014 7:06 AM, "Tina Holly" notifications@github.com wrote:

I got this error when adding roughly 20 files each with their set of
images (5-10).

The message before the error in question says:

info: Waiting on the following files on renderFiles:

It then lists files that failed to render. Eventually it says how many
were generated:

info: Generated 182/193 files in 27.36 seconds

As you can see, not all files have been generated.

I decided to see if I could avoid DocPad errors by deleting some of my
content for this section of the site—I needed to do that anyway. I deleted
a file and got the error specified and directions to come here. So, I'm
guessing the error happened in my case because the file is waiting to be
rendered, cannot be rendered, and is then deleted.

It seems as though DocPad cannot handle a large amount of files, be it
rendering from markdown or copying over from the static directory. I am
migrating some content from a PHP-based content management system over to
DocPad and I have about 20 child pages each with sets of images. Is this
too much for DocPad to handle? Content is being rendered with the markdown
plugin, and images are copied into the static directory. Some of the
markdown files have HTML in it but from what I understand, markdown can
handle that. Also, I do not see any parsing errors like I have before, so I
don't think the problem is in the markdown parsing (though I could be
mistaken).

Another related issue—I also got caught in an infinite loop during the
watching of the images directory, i.e. the /static/images/ directory is
watched and keeps logging "Changes detected at ... created /path/to/image"
and it would cycle through the entire directly infinitely, finding more
changes, and re-creating the images.

I'm running DocPad v6.69.1 and my plugins include cleanurls, eco,
highlightjs, ignoreincludes, livereload, marked, partials, sitemap, stylus,
thumbnails, uglify

I'm not sure if this is the best place to specify the infinite loop and
lack of being able to generate all files with a large amount of images and
a few plugins installed, but it could all be related somehow.


Reply to this email directly or view it on GitHub
#792 (comment).

Contributor
greduan commented Nov 14, 2014

What @dimitarkolev said. :)

Thanks for your quick responses! Using the raw plugin helped with that issue and the rendering is much faster, but it breaks the functionality I had going on with the thumbnails plugin to generate thumbnails. That plugin can no longer find the images, even after specifying the path. Is this an issue with the thumbnails plugin? Is there another way to have it ignore directories in static for the render/indexing passes without having to change the path? Has anyone used the two plugins together? Perhaps it's unrelated to this issue. If so, I would love to carry on the conversation elsewhere.

Unfortunately you are right about the thumbnails plugin. We had to write
our own plugin to take care of images. If someone knows the author of the
plugin I will gladly do a pull request, but the last time I did it, about
another issue with it it didn't make it to npm and jus to the repo.

May be I had to create thumbnails-raw plugin, please advise?
On Nov 15, 2014 3:08 AM, "Tina Holly" notifications@github.com wrote:

Thanks for your quick responses! Using the raw plugin helped with that
issue and the rendering is much faster, but it breaks the functionality I
had going on with the thumbnails plugin
https://github.com/rantecki/docpad-plugin-thumbnails to generate
thumbnails. That plugin can no longer find the images, even after
specifying the path. Is this an issue with the thumbnails plugin? Is there
another way to have it ignore directories in static for the render/indexing
passes without having to change the path? Has anyone used the two plugins
together? Perhaps it's unrelated to this issue. If so, I would love to
carry on the conversation elsewhere.


Reply to this email directly or view it on GitHub
#792 (comment).

As a workaround you can add the following to docpad.coffee

  events:
    extendCollections: (opts) ->        
      @docpad.getCollection('files').on 'add', (document) ->
        if document.get('url').indexOf('/hub') is 0
          require('mkdirp').sync document.get('outDirPath')
          document.setMetaDefaults(ignored:true)
        document.setMetaDefaults(standalone:true)          

What it does is that it marks all files in /src/files/hub folder as ignored which will speed up docpad indexing but thumbmails plugin will keep working. As you can see we recreate the directory structure in hub folder in the /out because otherwise thumbnails plugin will fail when generating thumnails.
The last line sets standalaone to all files which also improves generation speed.
Keep in mind that this solutions does not require raw plugin. And the images should stay in static(files) folder.

Do you have an example project with this code, @dimitarkolev? It doesn't appear to work. When running docpad run -d I can see that after it copies all of the files over, it chokes at this stage and can't generate. It appears to choke at the require('mkdirp') part. When omitted, I get the thumbnails error as you specified. Any suggestions?

Did you npm install mkdirp ?
On Nov 15, 2014 6:41 PM, "Tina Holly" notifications@github.com wrote:

Do you have an example project with this code, @dimitarkolev
https://github.com/dimitarkolev? It doesn't appear to work. When
running docpad run -d I can see that after it copies all of the files
over, it chokes at this stage and can't generate. It appears to choke at
the require('mkdirp') part. When omitted, I get the thumbnails error as
you specified. Any suggestions?


Reply to this email directly or view it on GitHub
#792 (comment).

I did and tried it again and it works. Thanks!

asatgs commented Dec 15, 2014

Getting the error below when I delete "about.html.md" in /render

error: An error occured:
Error: DocPad has encountered an invalid state while detecting changes for your files.
So the DocPad team can fix this right away, please provide any information you can to:
https://github.com/bevry/docpad/issues/792
  at _Class.changeHandler (C:\docpad\test1\node_modules\docpad\out\lib\docpad.js:3614:17)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.bubble (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:177:19)
  at _Class.bubble (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:490:36)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.bubble (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:177:19)
  at _Class.bubble (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:4:61)
  at _Class.watchr.children.(anonymous function).watch.listeners.change (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:490:36)
  at _Class.EventEmitter.emit (events.js:106:17)
  at _Class.close (C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:432:16)
  at C:\docpad\test1\node_modules\docpad\node_modules\watchr\out\lib\watchr.js:312:20
  at Object.cb [as oncomplete] (fs.js:168:19)
error: To report the above error, follow the guide at: http://docpad.org/bug-report

my specs:
win 7 x64
docpad v6.69.1 (build from source)
node v0.10.26
docpad-plugin-livereload v2.6.0
docpad-plugin-marked v2.2.1

This doesn't actually crash the site - DocPad continues to run w/o any problems, but it still would be great to have a fix for this.

Owner

This should be fixed from watchr v2.4.12 December 17, 2014 and above.

Closing unless someone reports it again.

@balupton balupton closed this Feb 19, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment