fix(chat): fetch the feed again on foreground when a load ran across a suspension - #972
Merged
Merged
Conversation
…a suspension loadFeed() joins a load already in flight, so start(), the launch foreground hook and a reconnect make one fetch. When the app was backgrounded while that load's requests were out, the foreground joined it too, and the feed stayed as the server had it before the app went away until the next trigger. The background hook now marks an in-flight load as interrupted. The next handleForeground() waits that load out and starts a fresh one instead of joining. A launch with no background in between still joins, so dedupesFeedLoads is unchanged. The owner of a load clears feedLoadTask only if it still holds its own task, so it can't drop the one the foreground started. MockConversations now reads the DM feed when the call arrives rather than after feedDelay, as a server would; the new test needs that to hold a stale answer in flight.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
When the app is backgrounded while a feed load is in flight, the next foreground joins that load and gets the feed as the server had it before suspension. A message that arrived while the app was away doesn't show in the chat list until the next refresh trigger.
loadFeed()joins a load already in flight on purpose:start(), the launch foreground hook and a reconnect all converge on it, anddedupesFeedLoadsasserts one fetch per feed. That stays. What changes:AppDelegate's.backgroundcase calls a newConversationController.handleBackground(), which marks an in-flight load as interrupted.shutDownForBackground()closes the database but doesn't stop the controller, so the load really can outlive the suspension.handleForeground()waits out an interrupted load, then starts a fresh one instead of joining. A launch with no background in between still joins.feedLoadTaskonly if it still holds its own task, so it can't drop the load the foreground started.MockConversations.getDmChatFeedreadsfeedwhen the call arrives instead of afterfeedDelay, the way a server answers with the state at request time. Without that the new test passes with or without the fix.New test
foregroundAfterBackgroundMidLoadRefetchesFeedfails withhandleBackground()stubbed out and passes with the fix.ConversationControllerTestsandChatListLaunchSyncTestspass (98 tests), includingdedupesFeedLoads.refetchAfterReconnect()has the same shape: a reconnect during an in-flight load joins it. This PR doesn't change that.