This is the best way to do this check, since it isn't subject to i18n
modifying the strings. The server feature was originally introduced
in zulip/zulip commit 709c3b50fcba333740bb337bac69a801dbbdc4ee.
Since it's only 1 year old and the outcome is quite bad if this check
weren't present, we preserve support for older servers.
This example makes use of get_alert_words, add_alert_words and
remove_alert_words, three methods that interact with the
/users/me/alert_words REST API endpoint.
The root issue here is that we had been using `None` as a way of
encoding `event_types` as being an argument to not pass to the server
in the API codebase, but the marshalling to send this over the wire
didn't handle that possibility correctly.
This was incorrectly "fixed" in
409bb587429ec4dcb1220a8ed85ec1618ffde0ed; the root cause of the issue
was the refactor to the new approach for registering API endpoints.
Having a default parameter as '[]' may not be an issue with the current
implementation, but general practice is to default to None and assign
a default list subsequently.
This removes the use of RuntimeError, and replaces it with a custom
error class called ZulipError. In a few places, we use a subclass to
make it easier for code to interact with the error type.
Previously, remove_subscriptions called the
PATCH /api/v1/users/me/subscriptions endpoint, which is more like
an ad-hoc endpoint for bulk adding/removing subscriptions for the
user that makes the request. However, making a DELETE request
allows an admin to pass in the `principals` argument to unsubscribe
other users from streams as well, which is more consistent with how
add_subscriptions works.
mypy with strict-optional led to examination of res.get('result')
calls potentially raising TypeError ('error' in None).
Server code indicates this is safe, and other nearby code assumes
presence of fields in 'res' also.
The API has aggressive retry logic for connecting to a
server, which may make sense for situation where you have
connection blips or server restarts.
When you're first connecting to the API, however, connection
failures are almost certainly a sign of misconfiguration, so
now we fail fast.
The bot lib takes advantage of this API change by catching the
ZulipError exception and exiting gracefully.
