There are some inconsistencies with the wording, grammar and punctuation returned to the user. We should standardise these errors.
Product Overview
Product Description
Actually all messages directly returned by the CLI are stored on a translation file should be easy to go through them and standarize them.
On the other side there are some error messages directly coming from the api, in this case we have 2 options.
(1) Also standarize the error messages on the api.
(2) Forcing api responses to always include a more explicit error id, so the CLI can map it against local errors.
Imho we should implement both, so we standarize the api in case any 3rd party client is using it, but we gain control over the CLI output.
Requirements & Dependancies
We should divide this feature on different iterations:
Iteration 1 : Define standard
We should agree on a specification for all error messages. This document must live on github.com/ernestio/ernest/docs and should describe exactly how error messages should look like. Additionally it should be referenced on the api-gateway and ernest-cli READMEs.
Iteration 2 : The list
A list of possible errors, at the api and cli level, must be created so necessary issues can be created. And create necessary issues.
Each issue will have to fix api or cli, and the relative problems on the ernestio/ernest integration tests
Iteration 3 : Error codes
Both api-gateway and ernest-cli must be able to work together based on predefined error codes. As this can be threated as a feature itself it will be managed on https://github.com/ernestio/ernest/issues/880
Preamble
Summary
There are some inconsistencies with the wording, grammar and punctuation returned to the user. We should standardise these errors.
Product Overview
Product Description
Actually all messages directly returned by the CLI are stored on a translation file should be easy to go through them and standarize them.
On the other side there are some error messages directly coming from the api, in this case we have 2 options.
Imho we should implement both, so we standarize the api in case any 3rd party client is using it, but we gain control over the CLI output.
Requirements & Dependancies
We should divide this feature on different iterations:
Iteration 1 : Define standard
We should agree on a specification for all error messages. This document must live on
github.com/ernestio/ernest/docsand should describe exactly how error messages should look like. Additionally it should be referenced on the api-gateway and ernest-cli READMEs.Iteration 2 : The list
A list of possible errors, at the api and cli level, must be created so necessary issues can be created. And create necessary issues.
Each issue will have to fix api or cli, and the relative problems on the ernestio/ernest integration tests
Iteration 3 : Error codes
Both api-gateway and ernest-cli must be able to work together based on predefined error codes. As this can be threated as a feature itself it will be managed on https://github.com/ernestio/ernest/issues/880