Watch Error: FSEventStreamFlushSync(): failed assertion

[tbremer]

I am getting the following error after Running "watch" task restarts

2015-03-02 11:19 grunt[7732] (FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'

Happens with these versions:

$ node 0.11.6 - 0.12.0
$ npm 2.5.1

Related Grunt Config:

...
watch: {
  sass: {
    files: [
      '<%= configs.sassPaths.answ_sass + configs.minimatch %>',
      '<%= configs.sassPaths.sass_lib + configs.minimatch %>'
    ],
    options: {
      nospawn: true
    }
  }
}
...

[crimann]

Get exactly the same message when watch restarts. Happens on several projects with different configurations and on two different Macs.

Tested with those versions:

$ node v0.12.0
$ npm 2.3.0, 2.5.0, 2.7.0, 2.7.1

[tannerlinsley]

This happens for me too

[TheBox193]

+1 Ditto

[lancepadgett]

Same here. Can't seem to find a solution...

[alphanull]

+1 Yeah, same here. Watch task seems to actually work, but nonetheless the message is a bit annoying. I am on Yosemite 10.10.2

[greenchapter]

Same here...

I think the problem is node.js in v0.12.0, on an older version no problems..

[infinityplusone]

Same problem. Upgraded to node.js v0.12.1, and it is still there.

[ThomasHoadley]

Same problem.

[greenchapter]

Does anyone write an bugreport to the nodejs guys?

[vemec]

Same here

$ node v0.12.2
$ npm 2.7.4
OSX 10.10.2 (14C1514)

grunt[22532] (FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'

[vladikoff]

If anyone wants to try this in io.js, should be fixed there.

[of6]

Still happening for me as well

node v0.12.2 npm 2.7.5 grunt-contrib-watch 0.6.1 OS X 10.10.3

This seems to happen more when it has to run an uglify or concat task. But both are at the latest version.

[woerndl]

Same here on

node v0.12.0 and v0.12.2 npm 2.5.1 and 2.7.4 grunt-contrib-watch 0.6.1 OS X 10.9.5

Happens only if I set the option spawn: false or nospawn: true. The tasks don't run correctly, it's not just the message for me.

Seams to work with node v0.10.26.

[SudoCat]

Same problem - Seems to be functioning fine, but always gives this error.

Node: v0.12.2,
NPM: 2.7.5,
grunt: 0.4.5,
grunt-contrib-concat: 0.5.1,
grunt-contrib-imagemin: 0.9.4,
grunt-contrib-uglify: 0.9.1,
grunt-contrib-watch: 0.6.1,
grunt-sass: 0.18.1,
OS X 10.10.2

(FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'

[jwgmeligmeyling]

Can confirm.

[yumyo]

same here

Node v0.12.2
grunt-cli v0.1.13
grunt v0.4.5
grunt-contrib-watch 0.6.1
OS X 10.10.3

[paulhayes]

I'm also experiencing this issue

OSX: v10.10.2
Node v0.12.2
Npm v2.7.5
Packages:
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

[digitalcraftco]

Same here. node: v0.12.0

Removing spawn from Watch > Scripts > Options:{ } stops the error. What is spawn anyway again?

[mikehdt]

Might this potentially be why? https://github.com/bdkjones/fseventsbug/wiki/realpath()-And-FSEvents

[juanbrujo]

@digitalcraftco solution worked with v0.12.7, removing all spawns from watch: {} task (even if they're false)

[digitalcraftco]

@juanbrujo Thanks for the follow up. Indeed this has fixed the issue for newer versions.

[Fishrock123]

Interesting. Is 0.11.6 the earliest node version this manifests in? We've had the above linked io.js issue for this for a while but haven't really been able to debug it.

[flekschas]

@digitalcraftco It defines whether a new task should be spawned or not. See https://github.com/gruntjs/grunt-contrib-watch#optionsspawn

Removing spawn from options does avoid but not fix the issue.

[tconroy]

+1 getting this as well still.

[teejayhh]

Interesting to note, as soon as you remove the spawn = false property the compile time jumps up dramatically, in my case from 0.3sec to 4.3sec !!

I just came across this error (with spawn set to false) maybe this is of help ->

(node) warning: possible EventEmitter memory leak detected. 11 change listeners added. Use emitter.setMaxListeners() to increase limit. Trace at StatWatcher.addListener (events.js:179:15) at Object.fs.watchFile (fs.js:1289:8) at Gaze._pollFile (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:329:10) at /Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:411:12 at Array.forEach (native) at /Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:409:11 at iterate (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/helper.js:52:5) at Object.forEachSeries (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/helper.js:66:3) at Gaze._initWatched (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:354:10) at Gaze._internalAdd (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:193:10)

[jlujan]

I see similar messages in a C app using libuv and uv_fs_event* I wrote as well. Linked to https://github.com/nodejs/node/issues/854 which mentions this issue.

[maruf89]

Absolutely nothing changed in my dependencies for the last month at least and I randomly just started seeing this

[Fishrock123]

@maruf89 Did you change OS X versions?

[maruf89]

No, I'm still on Yosemite 10.10.3 - The only thing that changed is I got a hard drive cable replaced but no software/npm deps changed

[ogmios2]

+1 having same issue