Two gaps around an already-correct takeover mechanism, not the mechanism itself. First: Player.ts/MusicBar.ts both wired onClose to a no-op, so the moment a takeover force-disconnected the old device its video/hls.js instance (or the persistent music bar) just kept running forever on a dead connection - both devices looked fully active, since nothing ever told the old one to stop or navigate away. Second: the obvious fix (call the same leave path Quitter uses) ran into a worse bug - POST /leave removes a member by userId alone with no staleness guard, so the old devices own leave call would have ended the NEW devices membership too. Fixed both: onClose now tears down local playback and leaves whenever this routes own explicit teardown has not already run, and the leave route (plus the client, which now sends its own deviceId) gained the same staleness guard the socket handlers already had, via a new PartyService.isStaleDevice. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| build.mjs | ||
| package-lock.json | ||
| package.json | ||
| tsconfig.json | ||