@eugenepaniot @dwilliams782 I've thought of this before. The reason for the panic here is to brute force prompt us there is bad input data so that we can take a look at it and fix it, i.e. I think it's useful for ripley to not be resilient here. If we log the error and continue instead, I'm worried we'll never know, unless we explicitly add STDERR checks wherever ripley is used.

If it skips incorrect req and exits with non-zero code, will it be fine? Or input data for ripley has to be properly prepared?

@eugenepaniot @dwilliams782 I've thought of this before. The reason for the panic here is to brute force prompt us there is bad input data so that we can take a look at it and fix it, i.e. I think it's useful for ripley to not be resilient here. If we log the error and continue instead, I'm worried we'll never know, unless we explicitly add STDERR checks wherever ripley is used.

If it skips incorrect req and exits with non-zero code, will it be fine? Or input data for ripley has to be properly prepared?

That would take care of the cronjob finishing in a Failed state, which is good.
I can't think of many command line tools that continue working when given bad input. Can you think of any? However, we do pass ripley a list of inputs, so maybe it's OK to log, have the cronjob tell us it failed and then we go and investigate the bad data. What's really important for me is to always investigate bad data and the cronjob completely blowing up forces us to do that.
If you think log bad input + non 0 exit code is the best way to go, let's do that.

@eugenepaniot @dwilliams782 I've thought of this before. The reason for the panic here is to brute force prompt us there is bad input data so that we can take a look at it and fix it, i.e. I think it's useful for ripley to not be resilient here. If we log the error and continue instead, I'm worried we'll never know, unless we explicitly add STDERR checks wherever ripley is used.

If it skips incorrect req and exits with non-zero code, will it be fine? Or input data for ripley has to be properly prepared?

That would take care of the cronjob finishing in a Failed state, which is good. I can't think of many command line tools that continue working when given bad input. Can you think of any? However, we do pass ripley a list of inputs, so maybe it's OK to log, have the cronjob tell us it failed and then we go and investigate the bad data. What's really important for me is to always investigate bad data and the cronjob completely blowing up forces us to do that. If you think log bad input + non 0 exit code is the best way to go, let's do that.

For example grep command:

bash-4.4$ grep Name /proc/1/mem  /proc/1/status
grep: /proc/1/mem: Permission denied
/proc/1/status:Name:	systemd

bash-4.4$ echo $?
2

I think it's ok to continue working, in non-critical sections, if possible, but change exitCode.