But still accept sha1 hashes, to allow the existing unsubscribe
links to still work. I'm planning to remove the sha1 backwards
compatibility in a month or so.
If the user uninstalls our GitHub app from their GitHub account then,
the next time we request an access token, we will receive a
HTTP 404 response from GitHub. Rather than throwing an unhandled
exception, Healthchecks will now show an error message to the
user saying "GitHub denied access to reposuch/andsuch".
The on_notify_done callback was accessing exception data incorrectly.
If there's been an exception in the thread, it will be re-thrown while
calling future.result(), and we must catch it with "try ... except"
instead of calling future.exception().
The mitigation is to not attempt GetObject calls if there have
been more than 3 S3 errors in the past minute. The implementation
uses the TokenBucket class that we normally use for rate-limiting.
An example scenario this is trying to avoid is:
* the S3 service becomes unavailable for 10 straight minutes.
Each S3 request hangs until we hit the configured timeout
(settings.S3_TIMEOUT)
* A client is frequently requesting the "Get ping's logged body"
API call. Each call causes one webserver process to become
busy for S3_TIMEOUT seconds.
* All workers become busy, request backlog fills up, our service
starts returning 5xx errors.
With the mitigation, during an S3 outage, only the calls that
retrieve ping's logged body will return 503, the rest of the service
will (hopefully) work normally.
Fixes: #1114
Instead of using SCRIPT_NAME / FORCE_SCRIPT_NAME, PATH_INFO
and their associated issues, update urls.py to add the subpath
to all routes. This allows us to get rid of several hacks:
* the uwsgi.ini magic which parses SITE_ROOT, sets SCRIPT_NAME
and fixes PATH_INFO
* set_script_prefix() in sendalerts
* chopping the subpath off an URL in hc.accounts.views._allow_redirect
The idea comes from @apollo13
in https://code.djangoproject.com/ticket/35985#comment:5
cc: #1091
