Repository navigation
Fix playlist import: pin YouTubeKit 0.4.9 (ANDROID_VR stream URLs now 403) - #140
Closed
ShawnMadadha wants to merge 1 commit into
Closed
ShawnMadadha wants to merge 1 commit into
ShawnMadadha wants to merge 1 commit into
Conversation
Every imported track resolved, then every ranged download got HTTP 403 → IngestError.streamURLExpired → re-resolve → 403 again → scheduleRetry kept the row .pending through 5 whole-track attempts (minutes of spinner) → .failed (orange retry badge). Reproduced on the iOS Simulator with a live probe: 0/8 tracks ready, every attempt "prep failed … streamURLExpired". Root cause: Packages/ContinuityKit/Package.resolved pinned YouTubeKit at 7cc8190 (2026-07-05), whose stream URLs come from the ANDROID_VR InnerTube client. Since mid-August 2026 YouTube serves only the first ~1 MB of those URLs and 403s the rest, so the app's 1 MiB ranged downloader dies on chunk #2 every time, with every User-Agent. Upstream YouTubeKit 0.4.9 ("Update YouTube Changes (August 2026)") switches to the visionOS/web clients plus an embed fallback; its URLs return 206 for every chunk. - Package.swift: depend on YouTubeKit `exact: "0.4.9"` instead of floating on `branch: "main"` (which resolved differently per machine and let the app silently fall behind). - Package.resolved: 0.4.9 / e5b7d03. - Tests/IngestTests/LiveIngestProbeTests.swift: opt-in live-network probe (skipped unless CONTINUITY_LIVE_PROBE=1) that drives the real PreparationQueue and prints the failing stage/error per track — the tool that found this. With 0.4.9: 8/8 and 6/6 tracks ready on the simulator. - AGENTS.md / CLAUDE.md: record the gotcha and the diagnosis recipe. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Collaborator
|
learn how to code bum |
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
2 participants
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.
Symptom
Import a playlist → every track spins on the loading badge for minutes → every track flips to the orange "retry download" badge.
Root cause
Packages/ContinuityKit/Package.resolvedpinned YouTubeKit at7cc8190(2026-07-05). That version obtains stream URLs from the ANDROID_VR InnerTube client. Since mid-August 2026 YouTube serves only the first ~1 MB of those URLs and returns HTTP 403 for everything after, with every User-Agent. Our downloader fetches 1 MiB ranges, so chunk #2 of every track 403s →IngestError.streamURLExpired→ re-resolve (same client, same result) →scheduleRetrykeeps the row.pendingthrough 5 whole-track attempts on the minutes-scale.trackcurve (that's the long spinner) →.failed.Upstream fixed this in YouTubeKit 0.4.9 — "Update YouTube Changes (August 2026)": visionOS/web clients + an embed fallback. Its URLs return 206 for every chunk.
Change
Package.swift: YouTubeKitexact: "0.4.9"(wasbranch: "main", which resolved differently per machine and let the app silently fall behind).Package.resolved→ 0.4.9 /e5b7d03.Tests/IngestTests/LiveIngestProbeTests.swift: opt-in live-network diagnostic (skipped unlessCONTINUITY_LIVE_PROBE=1). Drives the realPreparationQueuefor 4 video IDs + 2 search-query tracks and prints everycom.continuity.applog line, so the next YouTube change shows its failing stage and exact error in one simulator run.AGENTS.md/CLAUDE.md: the gotcha + diagnosis recipe.Evidence (iOS Simulator, iPhone 17, this morning)
prep failed … streamURLExpiredc=ANDROID_VR→ 403 ×4c=VISIONOS→ 206 ×4Also: app target builds against 0.4.9 (simulator, 0 new warnings), full ContinuityKit suite passes with the probe skipped by default, app launches and restores its session on the simulator.
An independent multi-agent review of the pipeline reached the same root cause; it also noted that the shared
IngestThrottlecool-down stretches how long a permanently-failing track spins (an amplifier, not the cause) — worth a separate follow-up, not needed for the fix.🤖 Generated with Claude Code