Gulp 4 parallel task error propagation limits

Direct answer

No. Gulp 4's gulp.parallel does not guarantee that sibling tasks are stopped when one branch emits an uncaught stream error. In practice, sibling branches typically continue executing until they finish on their own or the process exits after the unhandled error crashes Node.js. The core documentation does not describe an automatic sibling-termination mechanism.

There is a built-in, composition-level interception point: attach an error listener to the stream returned by gulp.parallel. However, this listener lets you observe or react to the failure; it does not cancel the other branches.

Established behavior versus inference

Well-established: gulp.parallel composes independent tasks into a single stream. Each task must signal completion via a returned stream, promise, callback, or async function. An unhandled error event on any branch propagates through the composed stream and, if unhandled, triggers Node.js's uncaught-exception behavior, terminating the process.

Likely explanation: The orchestrator does not implement a cancellation scope that can halt arbitrary in-flight streams when another branch fails. It starts each branch and waits for completion signals, but it has no built-in way to force sibling streams to abort.

Safe interception pattern

You can centralize error logging without an external plugin by listening on the composed stream:

const { src, dest, parallel } = require('gulp');

function styles() {
  return src('src/*.css').pipe(dest('dist'));
}

function scripts() {
  return src('src/*.js')
    .pipe(/* transformer that may emit 'error' */)
    .pipe(dest('dist'));
}

const build = parallel(styles, scripts);

build.on('error', (err) => {
  console.error('A parallel branch failed:', err.message);
  // Perform manual cleanup here; siblings are not auto-cancelled
});

exports.build = build;

Recommended steps for this case

1. Handle errors inside each branch. Attach .on('error', handler) to the streams within individual tasks so failures do not become uncaught exceptions.
2. Use the composition listener for observability and teardown. If a branch owns a watcher or a long-lived resource, expose a teardown function and call it from the composition-level error handler.
3. Do not rely on process exit for cleanup. Because sibling tasks may still be running when the process terminates, partial writes or open handles can remain.

Verification

Confirm your Gulp version and test with a minimal reproduction:

# Ensure gulp 4.x is installed
npx gulp --version

Build a parallel task where one branch emits an uncaught stream error and another branch writes a file after a delay. Observe whether the delayed write lands before the process exits.

One diagnostic question

Are the sibling tasks that must be stopped using stream completion, promises, or async functions? The signaling style determines whether a shared cancellation token or a stream-specific teardown is the appropriate pattern.