--concurrent deploys ignore failing scripts (start, grants, wsrep wait) and exit 0 #144

Summary

With --concurrent (or RUN_CONCURRENTLY set), a script that fails during deploy is printed and then ignored: the deploy exits 0 and reports success. This applies to every step run through the concurrent runner: start, after-start, the wsrep wait, pre-grants, grants, post-grants.

concurrent/concurrent.go, startTask:

out, err = cmd.Output()
if err != nil {
    fmt.Printf("Error executing goroutine %d : %s", num, err)
    //os.Exit(1)
}

RunParallelTasksByPriority returns nothing, so callers cannot see the error either.

Reproduction

Observed while testing #143: a MariaDB 11.4.13 Galera deploy with --concurrent on a host missing libssl.so.10 (the bundled libgalera_smm.so needs it). Every node failed to load the wsrep provider and abort, yet:

Error executing goroutine 2 : exit status 1Error executing goroutine 1 : exit status 1...
galera deploy rc=0

The same deploy without --concurrent exits 1 with the server error log.

Related gap

In the concurrent path (sandbox/sandbox.go), the wsrep wait is added to the execution list only inside if sandboxDef.LoadGrants, so joining Galera/PXC nodes (which do not load grants) are never waited on in concurrent mode. The sequential path waits on every node since #143.

Suggested fix

• Collect errors from the concurrent tasks and return them from RunParallelTasksByPriority; stop at the first failing priority level and make the deploy fail.
• Add the wsrep wait for every Galera/PXC node in the concurrent path, as the sequential path does.
• Test: a concurrent execution list with a failing command must return an error.

Not the default path and not used by CI, which is why it has gone unnoticed.