You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context
- Sometimes ArchiveOrg will send a HTML response:
- which are usually issues on their side like: “429 Too Many Requests” and “Item Not Avaiable”,
- but also caused an error on our side, since we always expected a JSON.
- We have two jobs that run for ArchiveOrg, both make requests, so this happens at different places/time, but need very similar error handling.
- We also wanted to take this opportunity to try to centralize more our error handling.
How
- Handling HTML errors
- I extracted a method json_parse we can use for our both requests. It rescues JSON::ParserError, and re-raises it as a more specific error or as itself.
- Then handle_archiving_exceptions deals with it.
- Other errors
- To make this more cohesive, I updated this to have the same behavior as when we are dealing with HTML errors,
- so we also re-raise the errors and handle_archiving_exceptions deals with it.
- On handle_archiving_exceptions:
- We had been dealing with ArchiveOrg errors directly in its module, but even if they are more ArchiveOrg related, I think it makes sense to centralize everything in handle_archiving_exceptions.
- I did some work before where we moved error handling inside get_archive_org_status
- 28941ec
- I think this might not be needed,
- but even if it is, I think it might make more sense for us to wrap this job with handle_archiving_exceptions?
- It would be easier for us to avoid duplication.
References: CV2-4482
PR 533
test"when Archive.org fails with Pender::Exception::ArchiveOrgError it should retry, update data with snapshot (if available) and error"do
162
+
test"when Archive.org fails with Pender::Exception::ArchiveOrgError it should not notify Sentry, it should retry, update data with snapshot (if available) and error"do
0 commit comments