Skip to content

fix(exec): stop failing asynchronous hooks with an empty error message - #81

Open
loicsapone wants to merge 1 commit into
automatephp:mainfrom
loicsapone:fix/async-hook-empty-error
Open

loicsapone wants to merge 1 commit into
automatephp:mainfrom
loicsapone:fix/async-hook-empty-error

Conversation

@loicsapone

Copy link
Copy Markdown
Contributor

When a hook runs on several servers, each one is executed by a child automate exec
process, and Context::execAsync() reported the failure from that process' error
output:

throw new \RuntimeException($child->getErrorOutput());

But ExecCommand writes the reason on the standard output:

$output->write($exception->getMessage());
return Command::FAILURE;

So the error output was always empty and the deployment stopped on a blank [ERROR]
block with no clue about what went wrong.

ExecCommand now reports on the error output, and the parent falls back on the
standard output, then on the exit code, so the message is never empty whatever the
child does.

Tests

New ContextTest, 3 cases (reported on stderr, reported on stdout, not reported at
all). The last two fail on main with an empty exception message.

ExecCommand itself is not unit tested: it builds its Ssh internally and calls
login() outside the try, so it cannot be exercised without a refactoring that
felt out of scope here.

@julienj

julienj commented Aug 9, 2026

Copy link
Copy Markdown
Member

Nice catch — I replayed your tests against main and they do fail with an empty exception message, so this is a real one. The quiet: true path in upload() is where it hurts most: a failing tar xzvf currently aborts the deploy with no information at all.

One thing before I merge: we still don't know which server failed. That's the whole point of the async path, and in quiet mode the exception is the only output the user gets. Keying $process by server name and prefixing the message would be a few lines.

Minor, take it or leave it: now that ExecCommand writes to stderr, the stdout fallback will mostly pick up PHP deprecations (CLI sends those to stdout), so it may occasionally present noise as the cause. And since Ssh::exec() throws with the command's full output, a failing composer install will render its entire log inside the [ERROR] block — right after the streaming callback already printed it. Truncating to the last few lines could be a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants