Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

users reducer: Handle all user updates from realm_user op: update #5386

Merged
merged 7 commits into from
May 23, 2022

Conversation

chrisbobbe
Copy link
Contributor

@chrisbobbe chrisbobbe commented May 20, 2022

And, to get there (and also just because it's good practice), write down with a Flow type what exactly we expect to get from servers in this event.

In particular, this is on the path to correctly resolving #5250, as well as #2900 / #5363, which are server release goals.

Replaces: #3403
Related: #3408

@chrisbobbe chrisbobbe requested a review from gnprice May 20, 2022 04:01
@chrisbobbe chrisbobbe added P1 high-priority server release goal Things we should try to coordinate with a major Zulip Server release. labels May 20, 2022
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @chrisbobbe! This looks great; tiny comment below, and a workaround for that Flow issue.

Comment on lines 47 to 49
return { ...user, ...event.person };
} else {
return user;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still keep the behavior of only allowing avatar_url and role
changes to apply to the state [1]. […]

[1] Because we've been wary of accepting server data that we haven't
    vetted; see 729655187.

And indeed we can now see that was well justified -- with the nice new type definitions, there are two kinds of these events where the properties don't actually line up with properties on the user!

@@ -51,22 +52,15 @@ describe('usersReducer', () => {

/**
* Check that an update event with supplied `person` works.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: describe('EVENT_USER_UPDATE' should update, e.g. to "EVENT > realm_user > update"

Comment on lines 59 to 60
// TODO: Try to make `user_id` optional again.
const check = (person: $PropertyType<RealmUserUpdateEvent, 'person'>) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a fix for this, which I showed you in the office. Here's a try-flow link for the exploration we did of this Flow issue.

Following the generic "server event" pattern Greg started in
979d283. We still convert avatar_url to our special AvatarURL form
at the edge, in eventToAction, for crunchy shell:
  https://github.com/zulip/zulip-mobile/blob/master/docs/architecture/crunchy-shell.md

Also, give a Flow type to the event itself as we receive it from the
server: RealmUserUpdateEventRaw. We should keep this up-to-date with
the server API documentation. (We also have RealmUserUpdateEvent,
for the slightly processed form that has AvatarURL.)

We still keep the behavior of only allowing avatar_url and role
changes to apply to the state [1]. But now, that code is in
usersReducer instead of eventToAction. For the reducer tests that
simulate actions changing *other* user data, that means they'd now
fail. So, skip them, with a plan to re-enable.

[1] Because we've been wary of accepting server data that we haven't
    vetted; see 7296551. The API doc seems to have been improved
    since then, and now we've written down a type for it. So now we
    can proceed more confidently, which is nice!
@chrisbobbe
Copy link
Contributor Author

chrisbobbe commented May 20, 2022

Revision pushed! Please hold off merging until I've done some manual testing, but you can look at the revision in the meantime if you want.

// Excluded: "When the owner of a bot changes." The `users` state
// doesn't include cross-realm bots.
test.skip('When the owner of a bot changes.', () => {
check({ user_id: theUser.user_id, bot_owner_id: (theUser.bot_owner_id ?? 1) + 1 });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this and the rest of this commit still introduce setting user_id, then that's cut in a later commit

Comment on lines +22 to 24
// TODO: Follow changes in the user's email address, whether while we're
// event polling or not.
email: string,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also went and added a mention of this case on #3408.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

The reducer still doesn't handle all these cases, so we can't
un-skip them yet. But now at least we're prepared to cover all the
cases once the reducer *does* handle them, soon.

See the list of cases in the doc:
  https://zulip.com/api/get-events#realm_user-update

The removed comment was wrong to say that we should exclude a test
for bot-owner changes. The users state doesn't include cross-realm
bots, it's true. But it does include regular bots, and those are the
bots that have owners.
@chrisbobbe
Copy link
Contributor Author

Thanks! Revision pushed, with the results of my manual testing: zulip/zulip#22103, and a commit at the tip that follows from that.

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! The revision looks good, with one nit below. Please merge at will.

Comment on lines 58 to 64
// This assertion is cumbersome. But it fills a
// gap in Flow's coverage…that apparently Flow
// doesn't announce by marking anything with
// `any`. Remove when doing so doesn't stop Flow
// from catching something wrong on
// `value` or `rendered_value`.
}: $Values<$NonMaybeType<$PropertyType<User, 'profile_data'>>>),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I like to mark situations like this with something like FlowIssue (no $) in the comment. That helps in finding it, either for a broad sweep for issues we've run into in Flow (perhaps to consider dropping the workarounds after a Flow upgrade occasionally?)… or for finding a specific issue one is thinking of but doesn't remember precisely where we encountered it.

See zulip/zulip#22103, which I sent after
observing that this was sometimes null.
@chrisbobbe chrisbobbe merged commit 5dc4770 into zulip:main May 23, 2022
@chrisbobbe
Copy link
Contributor Author

Thanks! The revision looks good, with one nit below. Please merge at will.

Thanks for the review! Merged, with that tweak.

@chrisbobbe chrisbobbe deleted the pr-all-user-updates branch May 23, 2022 23:41
@timabbott
Copy link
Member

It's really exciting to see this!

@chrisbobbe
Copy link
Contributor Author

Glad to hear it, Tim! You might also be excited to see that we've finally got round to #4933.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 high-priority server release goal Things we should try to coordinate with a major Zulip Server release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants