Skip to content

store: Implement removeAccount #1007

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

Merged
merged 9 commits into from
Oct 18, 2024
Merged

Conversation

chrisbobbe
Copy link
Collaborator

This PR was split out of #948, following #948 (review) , toward getting things merged more efficiently.

Related: #948

@chrisbobbe chrisbobbe requested a review from gnprice October 18, 2024 20:52
@chrisbobbe chrisbobbe added the integration review Added by maintainers when PR may be ready for integration label Oct 18, 2024
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! One comment below; otherwise all looks good.

Comment on lines 916 to 920
BackoffMachine? backoffMachine;

while (true) {
if (_disposed) return;

if (_debugLoopSignal != null) {
Copy link
Member

Choose a reason for hiding this comment

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

(followup on #948 (comment) )

Suggested change
BackoffMachine? backoffMachine;
while (true) {
if (_disposed) return;
if (_debugLoopSignal != null) {
assert(!_disposed);
BackoffMachine? backoffMachine;
while (true) {
if (_debugLoopSignal != null) {

I think a check at the top of the loop shouldn't be needed — it's not in itself right after an await, and we already have checks after each await.

Conversely an assert at the top of the whole method is good for the same reason as on other methods: it helps us catch if we're attempting to call the method when the object is already disposed, which would be a bug.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh indeed! Reading more closely, I see you did suggest putting it at the top of the method, not the top of the loop.

This seems hygienic. It makes sense to explicitly clean up an old
HTTP client's resources when we've set up a new one, for the
dead-queue reload. (The dead-queue reload is currently the only path
where this dispose method is called.)

It will also make sense to clean up these resources when an account
is logged out. That's a feature we'll be implementing soon, with
PerAccountStore.dispose in that new path as well.

The "abort long-poll and close ApiConnection" TODO was on
UpdateMachine's dispose method, not PerAccountStore's. But since
PerAccountStore is what owns the connection, its dispose method
seemed like the more appropriate place to close the connection.
@chrisbobbe
Copy link
Collaborator Author

Thanks for the review! Revision pushed.

@gnprice
Copy link
Member

gnprice commented Oct 18, 2024

Thanks! Looks good; merging.

@gnprice gnprice merged commit 03dfdf1 into zulip:main Oct 18, 2024
1 check passed
@chrisbobbe chrisbobbe deleted the pr-remove-account branch October 19, 2024 00:36
@chrisbobbe
Copy link
Collaborator Author

chrisbobbe commented Oct 19, 2024

Great! Just sent #1010 for the rest of #463.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants