Store server's version number, include in Sentry events

[gnprice]

When an error happens only on certain versions of the Zulip server, that can be a powerful clue for diagnosing it. I've often noticed when looking at Sentry events that I'd like to have that information. #3732 is a recent example that brought this to mind.

In implementing this, one layer is to use the Sentry API to get that information attached. I'm not sure how best to do that; @ray-kraesig has studied those docs recently and may have ideas.

The other layer is to get and keep the server-version information around in the first place. The server reports its version number in the server_settings response, but we don't currently store it anywhere; the only things we use the server_settings response for are at initial login, so we fetch it once then. It wouldn't do to just store it then, either, because of course the version (and other parts of that response) can change over the months and years the user might stay logged in.

Here's a plausible approach:

• Add a property like serverVersion to the Account type, found in the accounts state-subtree. Can be null | string.
• In the login flow, save the version we get.
• At the same time we call /register aka registerForEvents, in doInitialFetch in fetchActions.js, make a /server_settings request again and save the new version value.

The server version number could also be useful if we decide to condition on it for certain API changes, as suggested at #3732 (comment) .

[rk-for-zulip]

In implementing this, one layer is to use the Sentry API to get that information attached. I'm not sure how best to do that; @ray-kraesig has studied those docs recently and may have ideas.

Sounds like a job for either tags or extras. We probably want something like this when handling the server_settings response:

Sentry.configureScope(scope => { scope.setTag("server-version", "2.2.7723"); });

Note that I haven't tried tags out yet, so I'm not sure what they look like in Sentry – but extras are used in #3733.

[gnprice]

Sounds like a job for either tags or extras.

Thanks!

Between those two, I agree with your example that we probably want tags. Seems like the main difference is that tags get indexed, searched by, and aggregated on -- all of which sound like useful things for the server version.

Thinking about the search and aggregation, one thing that occurs to me is we likely want several tags here:

• the full version string, for complete information (e.g. 2.1.0-66-gd8a2ec0, the current value of curl -s https://python.zulipchat.com/api/v1/server_settings | jq .zulip_version -r)
• one or two simplified version strings, making it more coarse-grained for aggregation. (e.g. 2.1, or for explicitness perhaps 2.1.x)

[rk-for-zulip]

One reason I'm not sure we want tags is because they may also get disaggregated on – that is, a truly client-side-only issue might end up separated into fifty different issues just because the clients exhibiting it are connected to fifty different server versions.

(The links at the top of this documentation describe ways to customize the grouping, though, so even if that does happen we can probably override it.)

[gnprice]

Mmm, I see. I think that's not what will happen because the examples include:

The version of your platform (e.g. iOS 5.0)

and so I expect it to behave like the existing fields of that flavor do: they don't affect how the events get grouped into issues, and instead they get counted up across all the events of an issue to produce the graphs seen at the RHS of an event page.

But yeah, if we get surprised in that respect then we'll figure out a way to deal. 🙂

[chrisbobbe]

I can make a PR with the following —

• Add a property like serverVersion to the Account type, found in the accounts state-subtree. Can be null | string.
• In the login flow, save the version we get.
• At the same time we call /register aka registerForEvents, in doInitialFetch in fetchActions.js, make a /server_settings request again and save the new version value.

— and then the other things that depend on the server version (Sentry logging, etc.) can follow, right?

How's this for a workflow: I'll assign this issue to me, submit the PR without a Fixes: mark, and un-assign this issue so the rest of the stuff can be done? (I'm happy to do the rest but it sounds like we have more discussion to do about Sentry, etc.)

First, is there a reason not to just store the entire object received from server_settings?

[chrisbobbe]

It seems like the server_settings data (whether just the server version or the whole object) would make sense if made part of both the REALM_ADD and REALM_INIT actions; does this seem right conceptually? The alternative is most likely to create a new action.

[chrisbobbe]

OK, so from our chat earlier:

First, is there a reason not to just store the entire object received from server_settings?

Yes, we don't need all that stuff. Just the version number is fine.

It seems like the server_settings data (whether just the server version or the whole object) would make sense if made part of both the REALM_ADD and REALM_INIT actions; does this seem right conceptually? The alternative is most likely to create a new action.

Right, those seem to make sense.

[rk-for-zulip]

OK, so from our chat earlier:

First, is there a reason not to just store the entire object received from server_settings?

Yes, we don't need all that stuff. Just the version number is fine.

Maybe not all of it, but we do want some of them in support of other issues. realm_icon is needed for #392, and realm_uri is needed to properly fix... er, the issue that #3671 is intended for.

[gnprice]

Maybe not all of it, but we do want some of them in support of other issues. realm_icon is needed for #392, and realm_uri is needed to properly fix... er, the issue that #3671 is intended for.

True! I think we don't want to keep the bulk of it, though (which stops being relevant after we log in.) So I think it'll make most sense to pick out the bits we want selectively, as we add code that wants to use them.

[chrisbobbe]

I think we don't want to keep the bulk of it, though

This risks becoming a tangent, but we do at least pass the entire object in dispatch(navigateToAuth(serverSettings)); (RealmScreen.js)

[chrisbobbe]

This risks becoming a tangent, but we do at least pass the entire object in dispatch(navigateToAuth(serverSettings)); (RealmScreen.js)

(As noted in-person, this is a one-off use of it and not really a concern.)