Reader: Unsubscribe from Post object changes when toolbar disappears to avoid crashes #22147
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.


Fixes #22116
ReaderDetailToolbar can remain active in one tab while changes to the Post object can happen in another tab. To avoid issues, unsubscribe to Post changes when the view disappears.
I could not reproduce the crash but based on the logs the crash would happen during logout when accessing
likesCountinReaderDetailToolbar. It looks like Post observer is triggered during the logout process and the app crashes when we try to access no longer valid Post object. It happens because we remove Post observer inReaderDetailToolbar.deinit()which isn't called when we switch from Reader tab to Me tab.Solution
Connect Post observing to
ReaderDetailViewControllerlife cycle.The other option I considered is moving all the observation logic to
ReaderDetailViewControllerand then call specific methods ofReaderDetailToolbarto update the view. Do you think that would be preferable?To test:
Open Reader Details, and then switch tabs, for example:
unsubscribePostChangesis calledsubscribePostChangesis calledRegression Notes
When Reader Detail view disappears, we stop observing likes and comments. If that wasn't intentional, then it could be an indented area of impact.
What I did to test those areas of impact (or what existing automated tests I relied on)
What automated tests I added (or what prevented me from doing so)
PR submission checklist:
RELEASE-NOTES.txtif necessary.UI Changes testing checklist: