[Offline Pages] RequestPicker needs to remove requests it detects have had too many attempts |
||||
Issue descriptionCurrently, the RequestPicker will filter out requests for consideration that have had too many started attempts or completed attempts but it does not actually remove them from the queue (not report to observer that they failed) so a corresponding Download notification will continue to animate until the request is expired or canceled by user. Note many cases of too many attempts will be covered by the Coordinator (if the OfflineDoneCallback is called) but cases where that callback is not called (crash or killed by android during processing) will have this problem. See lines 145 and 149 of Oct 11 version of request_picker.cc.
,
Oct 12 2016
Sure, actually I expect to be part of Pete's refactoring into Tasks rather than just fix current RequestPicker logic.
,
Oct 12 2016
OK. Got it.
,
Nov 4 2016
Not cleaning up these requests means the notification remains actively animating. We need to clean these up and cause the NotifyComplete to fire for them.
,
Nov 4 2016
It looks to me like requests with too many completed attempts are removed in OfflinerDoneCallback, and requests with too many started attempts are removed in AbortRequestAttempt.
,
Nov 4 2016
Yes, but IFF OfflinerDoneCallback is called for that request. So if chrome killed or crashes while offliner in progress, that callback never happens and the picker will never pick it again and so it will stay until 7 day expiry with animated notification. This happens will crash loop or resource taxing request where android kills us where the start count reaches the limit.
,
Nov 4 2016
Btw, I saw this when Dmitry was trying his svelte device and saw that his download attempts where not completing. In that case, he was hitting the the background bytes UMA DCHECK crash we were seeing a couple weeks ago.
,
Dec 2 2016
Moving to M57, this is not important enough to need to be in M56.
,
Dec 2 2016
Issue 650480 has been merged into this issue.
,
Dec 21 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by fgor...@chromium.org
, Oct 12 2016