The bug: the Log page would sometimes show a number of "zombie"
notifications at the very end: notifications that should not be
shown to the user, but have not yet been garbage-collected.
The fix: when preparing the created__gte filter value for the
notification query, make sure the filter value is not lower than the
timestamp of the oldest visible ping.
* typo correction in README.md
* when opening the "ping details" dialog, by default set the active tab to "HTML" (if html content exists), otherwise set the active tab to "Text".
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.
The bug: _get_events sometimes does not have enough data to
calculate all durations correctly (some needed "start" events
may be outside the fetched data). The fix is to fall back to
Ping.duration() in these cases.
The code in hc.front.views.ping_details calculates durations
and sets them on the Ping.duration field, overriding the cached
property. But, it only does this for pings where the duration can
be calculated. If there's a streak of "success" pings with no
"start" pings between, the loop will not set the Ping.duration
field for most of them. So, when rendering the template, the
property code will run and cause an additional SQL query for each
ping. The fix is, in hc.front.views.ping_details, to set the
Ping.duration field for each and every ping.
* Added duration to ping details. This is useful on a device with a small screen, since the duration cannot be seen in the main view so now one can see it in the ping's details.
* Changed terms across the board from "delta" to "duration"
* timedelta is now consistently imported as "td" across the entire project (even in Django generated migration files)
Ordering by id causes Postgres to pick a bad
index (api_ping_pkey). Ordering by n gives equivalent results,
but Postgres picks a better index (owner_id)
Fixes: #705
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.
