Do not raise an error when a service is already started #131
Conversation
There was a problem hiding this comment.
I would stay with an error in that case. Bash Scripts, ci tasks (any other tools/script/etc... for automation) might use the cli return code. Returning an error might significantly help debugging such scripts/tasks.
Also starting a service that has already been started should rather give an error (the same as deleting/stoping something that has been already deleted/stopped etc...).
|
Having these errors is really not developer-friendly. When developing a service we can have this error for example with the dev command, also the workflow that will create and start the service based on the hash or whatever. All this is just blocking the user. That's why I still kept the warning, it's important to know but it doesn't need to crash the task. And for the part of a script using the cli then, in that case, the script will not crash and you will still have the instance of the service to continue your script. Having an error will sure help but having no error will just remove this problem and you will still be able to handle the real errors like the connection to the engine or stuff like that. |
Why so? The errors tells the story and you can move on with developing.
How this is blocking the user, i don't get it :(
On backend side, Script/Task automation doesn't work that way if you remove the error you won't have any pbm. It's rather opposite and my comment was exactly about that. On backend It's more like if you remove the error you will have more pbms. And backend/automation/etc perspectives should also be taken within each PRs. Still I don't see how the PR affects developers, but I see a lot of troubles with setting it up. |
src/utils/error.ts
Outdated
| } | ||
|
|
||
| export const resourceHash = (err: Error, resource: string): string => { | ||
| const reg = new RegExp(`${resource} \"(.*)\" already exists`) |
There was a problem hiding this comment.
This should be done using the gRPC Error code... This is not an small fix as the Engine needs to be updated. But using a regex is a hack.
There was a problem hiding this comment.
definitely agree but unfortunately, for now, the engine doesn't return proper error code.
antho1404
force-pushed
the
feature/start-error-handle
branch
from
8262d53
to
7cb8482
Compare
|
I did some updates, now the error is still triggered but typed and can be caught by the dev/compile commands |
When a service is started and we execute the command
service:startwe have an error.Now the command will catch the error, display a warning and return the hash based on the error.