If there is any issues putting objects then these should be reflected in the Check API

[brendanheywood]

ERROR: copy /var/lib/sitedata/filedir/17/51/xxxx to s3://sitedata-xxx-moodle/17/51/xxxxx: Error executing "PutObject" on "https://sitedata-xxxx-moodle.s3.ap-southeast-2.amazonaws.com/17/51/xxxx"; AWS HTTP error: Client error: PUT https://sitedata-xxxx-moodle.s3.ap-southeast-2.amazonaws.com/17/51/xxxx resulted in a 403 Forbidden response:

AccessDeniedAccess Deniedxxxxx (truncated...)
AccessDenied (client): Access Denied -
AccessDeniedAccess Deniedxxxxxxxxxxxx

Generally if there is an issue like this then it is likely that none of the subsequent PutObject will work either, but on the off change that it was a temp glitch then lets be forgorgiving and capture how many errors there are.

If there is constant errors and none are working then it should exit with a fail delay and that will turn up in the check api.

If there is a small rate of errors then ideally the task itself keeps running and those errors end up in the check api in some other way

[brendanheywood]

If it cannot put an object, it should try and read from it and see if it is already there, and if so just gracefully recover