Currently, com.suse.salt.netapi.utils.SaltErrorUtils will look for two classes of errors (FunctionNotAvailable, ModuleNotSupported). There are other classes that could be handled (I don't remember the circumstances for all of these, and some could be unique to running the salt CLI command):
TypeError encountered executing ** Passed invalid arguments *ERROR executing *ERROR: *The following keyword arguments are not valid *
Then there is the exception class The minion function caused an exception which is followed by a Traceback and exception message
And then there are 3 messages that indicate the func never even made it to a minion (again, some may be unique to the salt CLI):
Minion did not returnThe master is not respondingNo minions matched the target
I could volunteer to start adding some of these (those that are known to happen when using the salt-api server). However, the current design is not fun in terms of maintaining. It seems each new SaltError impl casues the SaltError fold method's signature to need to change, thus requiring all existing SaltError impls to change. I don't really understand the pattern, so I don't' have a suggested re-design of that, but would prefer something simpler before embarking on adding more error handling.
Currently, com.suse.salt.netapi.utils.SaltErrorUtils will look for two classes of errors (FunctionNotAvailable, ModuleNotSupported). There are other classes that could be handled (I don't remember the circumstances for all of these, and some could be unique to running the
saltCLI command):TypeError encountered executing ** Passed invalid arguments *ERROR executing *ERROR: *The following keyword arguments are not valid *Then there is the exception classThe minion function caused an exceptionwhich is followed by a Traceback and exception message And then there are 3 messages that indicate the func never even made it to a minion (again, some may be unique to thesaltCLI):Minion did not returnThe master is not respondingNo minions matched the targetI could volunteer to start adding some of these (those that are known to happen when using the salt-api server). However, the current design is not fun in terms of maintaining. It seems each new SaltError impl casues the SaltError
foldmethod's signature to need to change, thus requiring all existing SaltError impls to change. I don't really understand the pattern, so I don't' have a suggested re-design of that, but would prefer something simpler before embarking on adding more error handling.