fix: stop the XHR seed path from pre-empting the seeded collection - #684
Merged
Conversation
The seeding added in this PR never ran. On-device the log shows xhr_seed_triggered present and native_settled entirely absent: 20:49:47.914 keep-one.register (initial) 20:49:48.3-.7 three native continuations 20:49:48.883 batch_fetched (unseeded, from the seed path) ...no reload... 20:49:54.979 continuation.detected -> from_native -> reload Two faults, both mine: 1. The XHR seed path fires on the FIRST continuation request, roughly 400ms in and well before the 1200ms settle timer. It sets __ttPrefetchStarted, so when the timer did fire autoStartCollect bailed at its own guard and the seeded run never happened — collection restarted from batch 2 exactly as before the change. It now stands down while the settle timer is armed, since a run started there has strictly worse information. 2. That path's completion only ever called _triggerReveal, never the cache/reload. So it could finish a complete collection and still leave the page alone — which is what was seen: batches loaded, no reload, and the page only corrected itself six seconds later when a manual scroll produced the final native batch. It now does the same storeFullPlaylist + maybeReloadForFullPlaylist as the scheduled path, so whichever path runs, the reload happens. Also clears __ttNativeSettleTimer as the timer fires. The seed path reads a set handle as "the scheduler owns this", and setTimeout handles do not self-clear, so it would have deferred forever and lost its fallback role.
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 seeding from #683 never actually ran. On-device:
xhr_seed_triggeredpresent,native_settledentirely absent.Two faults, both mine:
The seed path wins the race. It fires on the first continuation request (~400ms), well before the 1200ms settle timer, and sets
__ttPrefetchStarted— so when the timer fired,autoStartCollectbailed at its own guard and the seeded run never happened. Collection restarted from batch 2 exactly as before. It now stands down while the settle timer is armed.That path never reloaded. Its completion only called
_triggerReveal, never the cache/reload — so it could finish a full collection and still leave the page alone. That's the "batches loaded but no reload, had to scroll" behaviour; the page only corrected itself 6s later when a manual scroll produced the final native batch. It now runs the samestoreFullPlaylist+maybeReloadForFullPlaylistas the scheduled path.Also clears
__ttNativeSettleTimeras the timer fires — the seed path reads a set handle as "scheduler owns this", and setTimeout handles don't self-clear, so it would have deferred forever and lost its fallback role.