If auto-remediation fails for whatever reason, that's it for that pdf. It has a 'remediation_started_at' date, so it will never again be sent to our remediation-api. It would be nice to have the ability to retry, in case there's a failure that might succeed if tried again (such as a momentary adobe outage). Also, it will make our display on the ETDA Explore ("We're generating an accessible copy") actually true.
Upon receipt of a 'job.failed' event_type from the pdf api, reset the 'remediation_started_at' and 'remediation_job_uuid' to nil. This will allow them to try again.
We should also continue implementing something that caps the number of times a pdf can be sent to autoremediation, to prevent someone from spamming the api.
If auto-remediation fails for whatever reason, that's it for that pdf. It has a 'remediation_started_at' date, so it will never again be sent to our remediation-api. It would be nice to have the ability to retry, in case there's a failure that might succeed if tried again (such as a momentary adobe outage). Also, it will make our display on the ETDA Explore ("We're generating an accessible copy") actually true.
Upon receipt of a 'job.failed' event_type from the pdf api, reset the 'remediation_started_at' and 'remediation_job_uuid' to nil. This will allow them to try again.
We should also continue implementing something that caps the number of times a pdf can be sent to autoremediation, to prevent someone from spamming the api.