Skip to content
Snippets Groups Projects
  1. May 27, 2023
  2. May 26, 2023
  3. Apr 21, 2023
  4. Feb 25, 2023
    • Marc Troelitzsch's avatar
      #266: Add new Site.patrol function · 9359fd69
      Marc Troelitzsch authored
      9359fd69
    • Adam Williamson's avatar
      Merge pull request #286 from AdamWill/api-sleep-raise · 5b9ee7dd
      Adam Williamson authored
      API calls: raise original exception when retries exhausted
      5b9ee7dd
    • Adam Williamson's avatar
      API calls: raise original exception when retries exhausted · 30b43690
      Adam Williamson authored
      
      This is an alternative approach to solve the problem identified
      in #279 . When doing API calls with `retry_on_error` set to
      true (the default), if the call fails after all retries are
      exhausted, we raise our own `MaximumRetriesExceeded` exception,
      which tells you nothing about what actually went wrong, just
      that we exhausted the retry count. It seems much more useful
      to raise an exception with information about why the connection
      is failing.
      
      This changes that behaviour so that, on most paths, we would
      raise an appropriate exception from requests (either the one
      we caught, or an HTTPError via `raise_for_status`) if we exhaust
      the retry count. Only if we fail due to database lag would we
      still raise `MaximumRetriesExceeded` (because there isn't really
      an underlying exception we can handily raise in that case).
      
      Note that it was already possible to hit
      `stream.raise_for_status()` before this change, if the status
      code was outside the 500 range, so in theory callers should
      already be prepared for that. It was not possible to get a
      `requests.exceptions.ConnectionError` or
      `requests.exceptions.Timeout` with `retry_on_error` true, though,
      so this is genuinely a behaviour change on that front.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      30b43690
  5. Feb 21, 2023
  6. Feb 19, 2023
    • Adam Williamson's avatar
      Handle page protection having no expiry (#290) · 44e6066f
      Adam Williamson authored
      
      Issue #290 gives an example of a wiki with protected pages whose
      protection definitions have no 'expiry' key at all. This seems
      strange and, on a quick through the mediawiki code, difficult
      to achieve, but since there's a live site out there that does it,
      and mediawiki *does* seem to have at least some code to handle
      such cases (e.g. how the expiry shows as 'indefinite' in the
      page information), let's handle it too, by representing this as
      None.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      44e6066f
  7. Feb 17, 2023
  8. Feb 16, 2023
  9. Feb 15, 2023
  10. Feb 10, 2023
  11. Sep 26, 2021
  12. Sep 22, 2021
  13. Sep 07, 2020
  14. Jul 08, 2020
  15. Jun 12, 2020
  16. Jun 08, 2020
  17. May 28, 2020
Loading