If every fetched ping is a success event, and has an unique
run ID, then we cannot determine the duration just from the
fetched data, and must fall back to Ping.duration(). This
would generate a SQL query per displayed ping.
The solution is to count how many times we would need to use
the fallback, and if it goes above some threshold (currently,
10 times), then disable duration display altogether.
I found a bug in the downtime statistics calculation. The
scenario:
* at T=0 a check goes down
* at T=5 some time later the user pauses it
* at T=10 the check receives a ping and goes up
If we don't record a status change (a flip) at T=5, then
the calculated total downtime will come out wrong (10)
This change fixes the pause views (hc.api.views.pause,
hc.front.views.pause) to create Flip objects.
I jumped the gun here, django-compressor doesn't yet have a Django 4.1
compatible release. With Django 4.1, "manage.py compress" currently
throws an error.
Checks can flip from "up" to "down" state as a result of changing
check's schedule. We don't want to send notifications when changing
schedule interactively in the web UI. So we update the `alert_after`
and `status` fields the same way as `sendalerts` would do. This is not
new, this was already being done.
With this change, we now additionally create Flip objects, recording
the fact that a check went down at such-and-such date. We fill the
"processed" field, to make sure sendalerts skips over these objects.
We need the Flip objects because otherwise the calculation
in Check.downtimes() could come out wrong (when a check later comes up,
we would have no record of when it went down).
The race scenario was as follows:
* Alice initiates email address change to bob@example.org
* a verification link is sent to bob@example.org
* separately, somebody creates a new account for bob@example.org
* Alice clicks on the verification link
At this point,
- if the database has an uniqueness constraint on auth_user.email,
Alice will receive a HTTP 500 error
- if there's no uniqueness constraint, the email change
will succeed and the system will have two accounts with the
same email address
The simple fix is to re-check the address availability just
before finalizing the email address change. Currently this is
not done in a transaction block, so the race condition still
exists in theory, but is much less likely to happen in practice.
