Open robross0606 opened 22 hours ago
Since Sywac is being used behind the scenes, and error handling documentation is sparse, here is an open issue thread discussing error handling: https://github.com/sywac/sywac/issues/63
While we're at it, are all those [object Object]
in the usage documentation intended?
Required Options
[--project-id] <project-id> [object Object] [object Object] [required] [string] [object Object]
Since the cli doesn't appear to accept "objects", it makes me think there's a bug in here related to toString()
.
Description
Invocations which do not have necessary parameters will return an error message along with help syntax and return a proper non-zero exit code. However, invocations which have enough info to make the REST call but fail due to server response return the raw JSON error response and do not react as a normal CLI tool would in that they do not output the error to stderr and do not result in a non-zero exit code. This makes its use in pipelines problematic because we must now somehow parse the response to understand it is an error. That somewhat defeats the purpose of the CLI tool, increasing complexity beyond using the raw API instead. Raw API tools like
wget
orcurl
recognize standard HTTP errors and have options to treat them as a proper exit code, which makes using this cli tool actually harder than raw API usage in many ways.Steps to reproduce
Invoke any bad call which has enough information to construct a call but fail on the server side:
Expected behaviour
The error response should be returned via
stderr
and the exit code should not be 0 (which indicates a success).Actual behaviour
The error response is return on
stdout
and the exit code is 0 which implies the cli command succeeded.Possible fixes
A failed call should at least result in an exit code other than 0. The cli tool does return a bad error code if incorrect number of required parameters are returned:
However, it does not result in a bad exit code if the REST call itself fails.
Checklist