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.
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
The API responses already contain ping_url, update_url, resume_url,
pause_url fields where the UUID can be extracted from, so we are
not exposing new information. The extraction can be finicky in,
say, shell-scripting scenarios. So for API user convenience we will
now also provide the check's code (UUID) as a separate field.
Fixes: #1007
We already have a MS Teams integration but MS Teams is discontinuing
the incoming webhook feature used by this integration:
https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-connectors-within-microsoft-teams/
MS Teams now recommends to use Workflows to post messages
via webhook. MS Teams does not provide backwards compatibility or
an upgrade path for existing integrations.
This commit adds a new "msteamsw" integration which uses MS Teams
Workflows to post notifications. It also updates the instructions
and illustrations in the "Add MS Teams Integration" page.
cc: #1024
This is primarily to make notification lookups by code efficient.
We look up notifications by code in hc.api.views.boundces.
This field has a default value (uuid.uuid4), so any null values
will be filled with random UUIDs during migration.
... and pass it to Transport.notify_flip().
This allows us to pass flip-specific information (the flip timestamp,
the new status) to transport classes.
I'm planning to change Channel.notify() signature to take a Flip
object as an argument instead of a Check object. This change is
in preparation for these changes.
In prune(), we need to look up the earliest ping in the database
for a given check. The old version did:
ping = self.ping_set.earliest("id")
The new version does:
ping = self.ping_set.earliest("created")
Both yield the same result, but in the first case Postgres may
decide to use the index for the api_ping.id column and scan
almost the entire table.
In the second case it uses the index for the api_ping.owner_id column,
and scans just the rows associated with the check.
