... and pass it to Transport.notify_flip().
This allows us to pass flip-specific information (the flip timestamp,
the new status) to transport classes.
This results in changes in other places too:
* curl.post() does not accept `data` as positional arg,
it must now be a keyword argument
* we need asserts and if clauses in a few places to make sure
we are not passing `None` in the arguments to hc.lib.curl.request
sendalerts had support for sending notifications
synchronously (with the --no-threads flag) and asynchronously using
threads (the default).
It turns out there was a bug in argument handling and sendalerts
was always using the synchronous mode regardless of the
presence/absence of the "--no-threads" flag. Since noone seems to
have noticed, I removed the unused async code.
The smtpd management command runs a SMTP listener for receiving
ping signals as emails. If emails arrive infrequently, the
database connections can time out. A brute-force workaround for
this was to call `connections.close_all()` before making new
DB queries.
Code moved around while migrating to aiosmtpd, and looks like
the workaround did not work any more – #847. This commit
replaces `connections.close_all()` with `connection.close()` and
moves it to the `_process_message()` function, which *hopefully* fixes
the problem.
* 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)
Channel.last_notify is the datetime of the most recent
notification sent via the channel. Channel.last_error is
the error message (blank if the delivery was successful).
In the integrations list, "Last Notification" column,
use these fields instead of looking up the most recent
Notification object. This saves some db queries,
and also fixes a subtle issue: if prunenotifications
cleans up all notifications for a given channel, the
"Last Notification" column would display "Never", which
would not be correct – not any more.
Profile.next_nag_date tracks when the next hourly/daily reminder
should be sent. Normally, sendalerts sets this field when
a check goes down, and sendreports clears it out whenever
it is about to send a reminder but realizes all checks are up.
The problem: sendalerts can set next_nag_date to a non-null
value, but it does not clear it out when all checks are up.
This can result in a hourly/daily reminder being sent out
at the wrong time. Specific example, assuming hourly reminders:
13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date remains set to 14:00.
13:55: Check B goes down. next_nag_date remains set to 14:00.
14:00: Healthchecks sends a hourly reminder, just 5 minutes
after Check B going down. It should have sent the reminder
at 13:55 + 1 hour = 14:55
The fix: sendalerts can now both set and clear the next_nag_date
field. The main changes are in Project.update_next_nag_dates()
and in Profile.update_next_nag_date(). With the fix:
13:00: Check A goes down. next_nag_date gets set to 14:00.
13:05: Check A goes up. next_nag_date gets set to null.
13:55: Check B goes down. next_nag_date gets set to 14:55.
14:55: Healthchecks sends a hourly reminder.
To send notifications, sendalerts calls Flip.send_alerts().
I updated Flip.send_alerts() to be a generator, and to yield
a (channel, error, send_time_in_seconds) triple per sent
notification.
