-
Notifications
You must be signed in to change notification settings - Fork 309
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
Conversation
We'll add more to this soon.
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.
Thanks! One comment below; otherwise all looks good.
lib/model/store.dart
Outdated
BackoffMachine? backoffMachine; | ||
|
||
while (true) { | ||
if (_disposed) return; | ||
|
||
if (_debugLoopSignal != null) { |
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.
(followup on #948 (comment) )
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.
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.
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.
a3b2e7c
to
03dfdf1
Compare
Thanks for the review! Revision pushed. |
Thanks! Looks good; merging. |
This PR was split out of #948, following #948 (review) , toward getting things merged more efficiently.
Related: #948