Repository navigation
Changing player route parameters leaves the previous video loaded while actions target the new ID #950
Description
Audited revision
develop at 36e968774bb41b222296a75b3a406c0be385badd. Read-only audit; no product fixes.
Problem and impact (P1)
The displayed/playing recording no longer matches the route. Download/share/delete read current streamId and can operate on recording 2 while recording 1 is displayed; notification navigation and Back/Forward can reach this reuse path.
Source locations
- app/frontend/src/views/VideoPlayerView.vue:247-250
- app/frontend/src/views/VideoPlayerView.vue:287-344
- app/frontend/src/views/VideoPlayerView.vue:394-425
- app/frontend/src/views/VideoPlayerView.vue:471-496
- app/frontend/src/App.vue:6-9
- app/frontend/src/router/index.ts:41-42
- app/frontend/src/router/index.ts:55-55
Reproduction and observed evidence
- Load /videos/1 and wait for Synthetic recording 1.
- Perform a normal in-app router.push('/videos/2') while the same VideoPlayerView instance is reused.
- The computed streamId changes but loadChapterData runs only onMounted; there is no watcher or router-view key.
Native Chromium URL is /videos/2, heading remains Synthetic recording 1, video src remains /api/videos/1/stream, and only /api/videos/1/chapters was requested.
Owner repeated the relevant Vue/Pinia probes (6 passed) and native Chromium cases (F02/F06/F07 passed) against this exact unmodified source. These tests deliberately assert the defect, not successful repair.
Verification boundary
The wrong-target delete consequence is established from the verified stale display plus current streamId action code. No wrong-target destructive backend operation was performed. No production data, credentials, external OAuth or provider calls were used.
Acceptance criteria
- Every relevant video route-parameter change loads the new metadata, chapters and media source and resets old player action state.
- Cancel/ignore obsolete asynchronous loads so a slower prior request cannot replace the new video.
- Until the new item is ready, destructive/share/download actions cannot target an ID different from displayed media.
- Browser regression covers video 1 to video 2, legacy-route equivalents and Back/Forward without a document reload.
Existing work / deduplication
Related: #921, #828, #933. no exact stale-route/action-target defect issue identified
Activity
Serph91P commentedon Nov 5, 2026
Final owner acceptance
Delivered through PR #981, regular merge
9e5d4e1c, followed by the strictly scoped new advisory correction #1046 / PR #1047, regular merge486899b5325541d0327c68c162bf81f2b8c1bf42. Expected parents, exact tested tree7f580954d5001e78154cb7f1d9a594217fc95e62and live develop ref verified. Original independent player review and bounded B1 correction review retained; no gate/policy/timeout relaxation.All three final merge pipelines are completed/success; original logs and current Security artifacts read:
Fresh real-backend browser acceptance was also repeated on the final composition with locked Python3.14.4/oauthlib4.0.1, actual app factory/auth/video/stream routers and cleanup worker, disposable SQLite/threeffmpegMP4s, network-isolated container and zero API response fulfills:
[1,3], share target2; file2 removed and files1+3 retained with unchanged hashes; destination/videos.image/svg+xml,1914bytes, byte-identical and HTTP200 offline through the actual installed service worker.The original postmerge failure on oauthlib4.0.0 remains historical RED, not relabeled as passed. The current patched develop evidence above supersedes it. Application-JS limits remain1196533raw/381000gzip; MOCK1196483/380556 leaves only50raw/444gzip bytes, REAL1193366/379615.
This closes only #950 and the concrete #1046 advisory correction. #900 original reload/draft preservation, #943 operational acceptance, #842 wider backend/security work and overall open-issue completion remain separate and open. Synthetic auth/media/PWA checks are not provider/physical-device/production acceptance.