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.
This parameter was intended to control whether we give a long timeout
and related behavior, but it was accidentally not being passed into
the second layer of the library from the first.
While we're fixing it, make it actually limit the length of a timeout
to something reasonable.
It is not guaranteed that the integration scripts in
the Zulip repository even specify a `provision` option.
Therefore, checking the value of this option would fail.
Updating this with getattr and a default value.
Previously, if you didn't specify a list of `event_types` in either `register` or `call_on_each_event`, you'd get an exception due to the invalid event format.
This fixes#86.
In order to keep all three packages (zulip, zulip_bots,
zulip_botserver) in the same repo, all package files must now
be nested one level deeper.
For instance, python-zulip-api/zulip_bots/zulip_bots/bots/, instead
of python-zulip-api/zulip_bots/bots/.
