Typing notifications are mistyped, resulting in rejection (for servers < 2.0)

[rk-for-zulip]

Per the docs for the typing-notifications API, the Zulip server expects to to be a list of email addresses, not a list of user IDs. Unfortunately, we're sending the latter.

The current version of the Zulip server appears to accept numeric IDs (@andersk, can you confirm?) but errors in Sentry indicate that responses from servers along the lines of Bad value for 'to': [17,42,105] do occur in the wild.

[andersk]

The typing notifications API seems to have gained user ID support as a side effect of zulip/zulip#10336 (2.0.0-rc1 and later), although our mypy types didn’t reflect this side effect until zulip/zulip#12950, so I’m not sure if anyone explicitly recognized this at the time.

[timabbott]

This was definitely an intentional change for Zulip 2.0. It's correct and preferred to send IDs for Zulip server versions that support doing so. I think probably the right implementation would be to have ID -> email conversion logic that runs only for server versions < 2.0.

[gnprice]

Hmm! Good to catch this.

It looks like on the client side the change happened in c631bdb / #3662:

-  api.typing(auth, narrow[0].operand, 'start');
+  maybeNotifyTyping(auth, recipientIds);

where I believe the old version would have sent a string like alice@example.com,bob@example.com. Seems like I/we missed that change in behavior.

I think probably the right implementation would be to have ID -> email conversion logic that runs only for server versions < 2.0.

Is the suggestion to condition literally on the server's version number?

We could do that. It's possible it'd be cleaner overall than an alternative of adding some kind of capability flag that the server has to communicate forever. The version number is in the server_settings response.

One short-term wrinkle in this approach is that we don't currently store the server_settings response; indeed we only fetch it at initial login. So we'll want to sort out when to re-fetch it, and where to store the version number. I've just filed #3745 for that -- along with including the information in Sentry events, which will be independently useful.

Per the docs for the typing-notifications API, the Zulip server expects to to be a list of email addresses, not a list of user IDs.

I'd forgotten this, but I filed that issue as zulip/zulip#13286 in October.

[gnprice]

Bumping priority because this is one of the handful of noisiest errors in our Sentry logs.

[gnprice]

#3839 is now merged, which is the main part of #3745 -- we now store and parse the server's version number.

I think that means this issue will be straightforward to fix from here: we just need to get the version number from Redux, compare to 2.0.0-rc1 (because the server change apparently happened then -- it'd be good to track down the exact commit, too), and use the new API only if it's at least that.