You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I feel there is one issue with this approach. Our commands call panic on error, which normally just exits the CLI with the error. In a case of a failure during executing the job worker we DON'T want to exit, we want to retry or fail the job.
This means we need to extract all logic used in the commands in separate functions to return errors, in the subCommands we can then call panic in our workers we have to handle the errors differently.
\cc @oleschoenburg
The text was updated successfully, but these errors were encountered:
Right now the
zbchaos worker
spawns a Zeebe worker and connects via the provided env vars to a camunda cloud cluster.It registers for the
zbchaos
job type and will forward all further commandslike verify readiness
, via calling root again. https://github.com/zeebe-io/zeebe-chaos/blob/main/go-chaos/cmd/worker.go#L115I feel there is one issue with this approach. Our commands call panic on error, which normally just exits the CLI with the error. In a case of a failure during executing the job worker we DON'T want to exit, we want to retry or fail the job.
This means we need to extract all logic used in the commands in separate functions to return errors, in the subCommands we can then call panic in our workers we have to handle the errors differently.
\cc @oleschoenburg
The text was updated successfully, but these errors were encountered: