Abort sequential chain on `task_error`

For instance:

export async function foo () {
    console.log('Perform foo');
}

export async function bar () {
    console.log('Perform bar');
}

export async function error () {
    throw 'Something went wrong!';
}

export default async function () {
    await this.start(['foo', 'error', 'bar']);
}

The tasks bar is performed even if the previous task has failed.

The expected result can be achieved with the following:

export default async function () {
    this.on('task_error', function () { process.exit(1); });
    await this.start(['foo', 'error', 'bar']);
}

but I feel it should be the default behavior especially for tasks like linting or testing which should abort subsequent compilation or packaging tasks.

The error is dismissed in the fly exec function:

*exec (task, value, inject = this) {
    _("run %o", task)
    try {
        const start = new Date()
        this.emit("task_start", { task })
        value = (yield this.host[task].call(inject, value)) || value
        this.emit("task_complete", {
            task, duration: (new Date()).getTime() - start
        })
    } catch (error) { this.emit("task_error", { task, error }) }
    return value
}

Either the error should be thrown or the fly start function should handle the task_error event.

I’m trying out fly and I didn’t see any error handling example or convention on the matter so maybe I’m missing something ? How should I properly abort a tasks chain ?

[throskam]

I agree, parallel tasks are creating new tasks chains that shouldn’t be impacted by any errors in other chains.

Typically it would be for use cases such as linting, compiling, packaging. It makes no sense to package if the compilation or linting process has failed.

[lukeed]

I’d only agree as far as sequential tasks (parallel: false) are concerned, but even then, no process should be exited.

Parallel tasks are independent of one another – that is the point, after all.