Fails on return

[thasmo]

Hey there!

AWESOME 🐒 patch, love it so much!

I noticed if I return the stream in a task, 'watch' freezes after a stream error:

gulp.task('styles', function() {
    return gulp.src('application/static/style/*.scss')
        .pipe(plumber())
        .pipe(sass())
        .pipe(gulp.dest('public/static/style/'));
});

If I remove 'return' it doesn't freeze, when an error occurs:

gulp.task('styles', function() {
    gulp.src('application/static/style/*.scss')
        .pipe(plumber())
        .pipe(sass())
        .pipe(gulp.dest('public/static/style/'));
});

Returning the stream is mentioned in the gulp docs here:
https://github.com/gulpjs/gulp/blob/master/docs/API.md#async-task-support

Thanks! :)

[floatdrop]

Thank you! But while I was writing a test for it, it turns out, that without plumber I got same behavior (not working, when returning a stream). Could you remove plumber and check this too? If so, this issue related with orchestrator.

[mrmurphy]

I'm seeing this behavior but only when my stream uses the gulp-sass plugin. I throw an error in the stream and plumber notifies me, but the watch task for sass stops completely. I also tried returning a promise instead of the stream, and using a callback instead of returning a stream. Neither of those worked either.

However, my coffeescript task works fine. I make an error there and I'm notified, but the watch task continues and I can fix the error without restarting gulp.

[laurelnaiad]

I've just discovered gulp-sass' propensity to kill my watch, as well. It's easy enough to have one syntax error from a designer and the whole thing blows up. I've figured out how to handle it.

Basically, you pass plumber a custom error handler. That error handler logs the problem (I just copied plumber's default handlers log message, plus a few key newlines)... and then your function closes down the watch that is now defunct.

(I keep track of the gulp-watch object and my connect servers, all of which have a close function, so I call that on each of them)

Then the function reinvokes the watcher function that I use to initiate the watch in the first place ,along with a message saying that I'm doing so. It actually works out pretty well. It just takes managing the state of a few things in order to end the current watch and start up a new one in good health. I have it set up so that it doesn't matter which plugin crashes the party, this behavior will kick in if plumber's patch detects and prevents me from the China syndrome.

[jtomaszewski]

So you're restarting gulp watch in the onError handler? Heh, seems like the only way to do it right now.

Could you show us some source of it ?

[heikki]

I had same issue with gulp-stylus. Emitting end from the custom error handler seems to fix it:

gulp.task('styles', function() {
    return gulp.src(paths.styles.src)
        .pipe(plumber(function(error) {
            gutil.log(gutil.colors.red(error.message));
            this.emit('end');
        }))
        .pipe(stylus({ use: [ nib() ] }))
        .pipe(concat('all.css'))
        .pipe(gulp.dest(buildDir + '/styles'));
});

[laurelnaiad]

@jtomaszewski my project is scheduled to go open source later this year and I'm not in control of that schedule. I'd organize a snippet for you, but I think @heikki's method makes more sense. I knew that my problem was the lack of an end event because it was obvious that watch didn't think its handler was completing, but it didn't occur to me to emit end from this in the error handler. That's going to wind up being cleaner, I can just feel it. In fact I'm going to undo some of my twists and turns right now. Thanks, @heikki.

[derekwheee]

+1 @heikki

[mmrko]

@heikki 👍

[gaving]

@heikki 👍

[pronebird]

Insane, this is really annoying, why does not plumber catch this or less/sass plugins automatically close pipe on error? That seems odd.. Why would plumber exist if I can add .on("error", ...) instead of plumber and handle error myself.

[laurelnaiad]

gulp-sass has a configurable onError handler which works for me (unless node-sass segfaults, which I hope is a thing of the past).

[floatdrop]

@pronebird when you have long pipeline - then you must add .on('error', ...) after each pipe which is very ugly.

We started to use gulp-less for a while and sooner or later I will get to this bug (if I can reproduce it).

[pronebird]

@floatdrop thanks for explanation. I encounter this error on gulp-less. Custom plumber error handler solved the problem.

Do you think it would make sense to fix plumber to close pipe on error by default?

[floatdrop]

@pronebird well, plumber purpose is to keep pipes working on errors. If you want to close pipe on errors - I think you should not use plumber at all.

[jmcbee]

How do I close pipe on errors? I'm experiencing this on gulp-sass as well. cheers!

[pronebird]

@fbm-static call this.emit('end'); in error handler for plumber. @heikki posted example above.

[heikki]

^ That may not be the right thing even if it seems to work ok.
http://www.bennadel.com/blog/2692-you-have-to-explicitly-end-streams-after-pipes-break-in-node-js.htm

[jmcbee]

@heikki when I do this.end() it does not seem to finish the task.

[callumacrae]

I'm having the same problem with gulp-compass, but calling this.emit('end') doesn't fix it.

[derekgreer]

this.emit('end') isn't working for me either.

After skimming the article referenced by heikki, I modified my code to the following which does work:

.pipe($.if(isWatched, $.plumber(function (error) {
  $.util.log($.util.colors.red(error.message));
  this.end();
})))

Note: I'm setting isWatched within my watch task because I really only want plumber to kick in when I'm watching stuff, not during my CI build.

[fanpei91]

@heikki Thank you!