Gulp task completion: diagnosing stream return versus done callback in series()

In Gulp 4 and later, tasks composed with series() must signal asynchronous completion exactly once, but the API accepts multiple mechanisms: returning a stream or promise, or declaring and invoking a done callback. The unresolved decision is which signal to use per task and whether mid-pipeline errors reliably abort the remaining sequence.

A task that declares no parameters and returns nothing is treated as synchronous, so asynchronous work started inside it can be cut off when the process exits. A task that declares done but never calls it causes Gulp to report that async completion was not signaled. Returning a stream or promise is idiomatic for file pipelines, yet attaching an error handler that only logs can make a failed pipeline report success. In series(), a failing task stops the remaining tasks, but exact fail-fast semantics and error wording vary by gulp/undertaker version, and Gulp 5 introduced different internals and Node requirements.

Should each task return its pipeline stream or promise instead of using the done callback? Is mixing signals—such as returning a stream while also calling done—unsupported and likely to mask or duplicate failures? How should error handlers be attached so that stream errors fail the task rather than being swallowed?