Looking at ways that error reporting could be improved now that we're using waitForTaskToken on these tasks.
Given the example we saw recently of a TLS cert verification error preventing login,
- that raises an error (I assume an
OpenSSL::SSL::SSLError error, we don't currently log the error class, but the message was SSL_connect returned=1 errno=0 peeraddr=XXX.xxx.XXX.xxx:21 state=error: certificate verify failed (self-signed certificate)), which we catch to log and then re-raise.
- The re-raised error gets caught, recorded, and increments
attempt, and then goes back to the start of the while !result && (attempt <= max_attempts) loop
- Once attempts are exhausted, the loops exist and, since there is no
result, we raise "FTP failed, no more retries: from '#{local_file}' to '#{cstr}'" (yields something like "Error": "RuntimeError", "Cause": "FTP failed, no more retries: from '#<File:0x00007f513f571123>' to 'ftps://tktk:*******@XXX.xxx.XXX.xxx:21/123456.wav'")
- That raised error is what is ultimately caught in
ftp.rb and triggers sf.send_task_failure to declare the task a failure.
So the end result is that anytime we hit that final raise, we always get a RunTime error, regardless of the cause.
Could we do something to preserve the underlying issue better, so that when we get to the send_task_failure, it has some additional useful info? The error that causes send_task_failure is what gets included in the Porter task result callback and becomes visible to a client app, so it could be beneficial to preserve more info throughout the run.
Looking at ways that error reporting could be improved now that we're using
waitForTaskTokenon these tasks.Given the example we saw recently of a TLS cert verification error preventing login,
OpenSSL::SSL::SSLErrorerror, we don't currently log the error class, but the message wasSSL_connect returned=1 errno=0 peeraddr=XXX.xxx.XXX.xxx:21 state=error: certificate verify failed (self-signed certificate)), which we catch to log and then re-raise.attempt, and then goes back to the start of thewhile !result && (attempt <= max_attempts)loopresult, weraise "FTP failed, no more retries: from '#{local_file}' to '#{cstr}'"(yields something like"Error": "RuntimeError", "Cause": "FTP failed, no more retries: from '#<File:0x00007f513f571123>' to 'ftps://tktk:*******@XXX.xxx.XXX.xxx:21/123456.wav'")ftp.rband triggerssf.send_task_failureto declare the task a failure.So the end result is that anytime we hit that final
raise, we always get aRunTimeerror, regardless of the cause.Could we do something to preserve the underlying issue better, so that when we get to the
send_task_failure, it has some additional useful info? The error that causessend_task_failureis what gets included in the Porter task result callback and becomes visible to a client app, so it could be beneficial to preserve more info throughout the run.