fix: hook the array-root continuation path too, so the native cache completes - #682
Merged
Conversation
…ompletes The accumulator added in the last PR never fired. On-device with it live, every continuation reaching the handler I hooked carried hasContinuation:true: playlist.continuation.detected itemCount:15 hasContinuation:true playlist.continuation.detected itemCount:15 hasContinuation:true playlist.continuation.detected itemCount:15 hasContinuation:true That is 15 initial + 45 = 60 of 68 items. The final batch — the 8 items carrying no continuation token, the one completion depends on — never appeared there at all. It arrives through processResponsePayload, the array-root JSON.parse path, which handles playlistVideoListContinuation separately and logs nothing. So the accumulator sat at 45 items waiting for a completion that could not come, and the slow re-download stayed on the critical path exactly as before: 20:05:03.141 .. 20:05:11.128 batch_fetched x4 20:05:11.131 full_cache.stored (via the collector, ~10s in) This is the same object-root/array-root split that has bitten this file before, where a feature added to one path silently misses the other. Hooked the array-root path as well, before its filterContinuationItems call for the same reason as the other one — after it, an all-watched batch is down to the single kept helper. Also deduped the accumulator by video id. Two handlers now feed it, and a response reaching both would otherwise put duplicate tiles in the cached playlist.
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.
The accumulator from #681 never fired. With it live on-device, every continuation reaching the handler I hooked carried
hasContinuation:true:15 initial + 45 = 60 of 68. The final batch — 8 items, no continuation token, the one completion depends on — never appeared there. It arrives through
processResponsePayload, the array-root JSON.parse path, which handlesplaylistVideoListContinuationseparately and logs nothing. So the accumulator sat at 45 items waiting for a completion that couldn't come, and the slow re-download stayed on the critical path:Same object-root/array-root split that has caught this file before. Hooked the array path too, before its
filterContinuationItemscall for the same reason as the other.Also deduped the accumulator by video id, since two handlers now feed it and a response reaching both would put duplicate tiles in the cached playlist.
Expected next run:
full_cache.from_nativeabout a second in, thenstored→reloading→injected, withbatch_collect.cancelledinstead of 8s ofbatch_fetched.