-
-
Notifications
You must be signed in to change notification settings - Fork 268
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
Feat: Respect Server Typing Duration Settings & Tests #1448
Feat: Respect Server Typing Duration Settings & Tests #1448
Conversation
82a5be9
to
80054aa
Compare
@neiljp Kindly review. I am unsure about the commit message style, though I have rebased the commits into one. |
@zulipbot add "PR needs review" |
a0684f7
to
5460544
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@criticic, appreciate your efforts on this PR!
Consider rebasing and squashing both commits into a single one. Creating an extra commit solely for addressing linting issues might be causing the isolated commits test failure (where each commit needs to individually pass tests).
Additionally, I'd like to mention a previous suggestion I received: consider setting up gitlint
to review your commit messages style and take a look at the repo's commit history for further reference.
5460544
to
e14d33a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@criticic Thanks for the PR - and for your patience in waiting for feedback 👍
The code in this PR looks fine to fix the issue 👍 To improve the quality of this PR and help with future contributions, I'd suggest considering the commit structure itself, as below.
My primary feedback would be that multiple things are changing in the one commit:
- the units are moving from seconds to milliseconds
- the UI code is moving to use the new model API (attributes)
- the model API values become dependent upon the server values
The latter is the key feature change for #1445, whereas the others are refactors which enable it. Separating these makes it easier to pin down which commits should change behavior and which should not, as well as use the commit text to describe each specific change. This helps with reviewing, and can highlight a lack of tests and other aspects. Commits can always be squashed together right before merging if it seems like a good idea, but splitting up can be more challenging as a final step :)
Note that the failed linting from earlier shouldn't occur when you keep each commit up to date individually.
Splitting this up into smaller commits would also give more experience following the commit style we use, as noted in the README, and which will be helped by using gitlint
.
Please check in on chat.zulip.org if you're unsure about anything :)
@neiljp thanks for the detailed feedback, ill implement the changes soon |
7242309
to
f06c9d7
Compare
f06c9d7
to
4ebd70d
Compare
87e43ab
to
e869900
Compare
1f78ab9
to
ddd2fdf
Compare
@zulipbot add "PR needs review" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@criticic Thanks for the update - can you see how the commit structure here communicates the changes cleanly?
I've left some further feedback, but it's mainly guidelines on test styling.
As per my first review, the core code remains fine 👍 I believe this was your first PR, so I hope you appreciate and understand how the changes in tests and commit structure help overall - and that these changes haven't slowed you down too much.
tests/model/test_model.py
Outdated
@pytest.mark.parametrize( | ||
"feature_level", | ||
[None, 185, 203], | ||
ids=[ | ||
"Zulip_2.1.x_ZFL_None_no_settings", | ||
"Zulip_7.0.x_ZFL_185_no_settings", | ||
"Zulip_8.0.x_ZFL_203_no_settings", | ||
], | ||
) | ||
def test__store_typing_duration_settings_default_values( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is broadly a great initial test, and I thought initially you might have planned to extend this to other values in the next commit, which would make it a little less strange to see this parametrize. However, you did split out the other test part, and in any case, to someone just reading this commit, it is a little strange to have these values in the parametrize given the behavior is identical for each value/id.
Typically I'd expect to see a test with no parametrize when a test is first introduced like this.
Including this split would be great when things are dependent upon feature level, so the parametrize part could be appropriate to the next commit.
tests/model/test_model.py
Outdated
@pytest.mark.parametrize( | ||
"feature_level, to_vary_in_initial_data", | ||
[ | ||
( | ||
204, | ||
{ | ||
"server_typing_started_wait_period_milliseconds": 7500, | ||
"server_typing_stopped_wait_period_milliseconds": 3000, | ||
"server_typing_started_expiry_period_milliseconds": 10000, | ||
}, | ||
), | ||
], | ||
ids=["Zulip_8.0.x_ZFL_204_with_settings"], | ||
) | ||
def test__store_typing_duration_settings_with_values( | ||
self, model, initial_data, feature_level, to_vary_in_initial_data | ||
): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see you split out this new test.
Since you have only one entry in your parametrize, it isn't necessary to use parametrize (though some old tests we have still do for now!). You can still set values like feature_level and to_vary_in_initial_state, and we often do so in the parameter list to the test (rather than simply in the test body), since that allows us to switch back to using parametrize later fairly easily, if it becomes necessary.
You may find it simpler to extract the 3 dict parameters out manually here, since it will make the asserts easier to read :)
Lastly, it would be useful to add asserts in the setup here, that the input parameters are not simply the same as the defaults - that would avoid this test accidentally passing.
ddd2fdf
to
89440c1
Compare
@zulipbot add "PR needs review" |
From ZFL 204, the server provides typing notification parameters in milliseconds; this change ensures that the default values are also in milliseconds (instead of seconds).
Stores the default typing notification parameters in the model. Code which previously accessed these values directly now queries the model instead. A test has been added to verify the new model values.
From ZFL 204, the typing notification durations were made server-configurable; this change uses those values when provided, or else uses the default values. A test has been added to check this behaviour. Fixes zulip#1445.
89440c1
to
6e8c47e
Compare
@criticic Thanks for the last update! I made some minor changes to the commit text and pushed back here, along with some small moves in the test you added in the last commit, to illustrate the points I made above. I'll merge this after it passes CI, which shouldn't be a problem :) |
What does this PR do, and why?
As introduced in ZFL 204/Zulip 8.0, the typing duration values should no longer be hardcoded into the clients, and the server will provide those values. In case the values are not present, the previous defaults are used. I have also added tests to check for this behaviour.
Outstanding aspect(s)
External discussion & connections
Respect server typing notification settings #T1448 #T1445
How did you test this?
Self-review checklist for each commit