Voice channel move: user disappears from list but audio still plays in original channel

Observed behaviour

When a user is dragged (moved) from one voice channel to another by a moderator, the user disappears from the channel list in the UI but their audio is still heard by other participants in the original channel. The moved user appears to be in the destination channel visually, but their voice stream is not properly transferred — it remains connected to the original channel's LiveKit room.

UI updates correctly (user moves in the list)
Audio stream stays connected to the original channel
Creates a "ghost audio" situation

Expected behaviour User A should be fully moved to channel 2: audio transfers to the new channel and is no longer heard in the old one.

Reproduction steps

User A joins voice channel 1
User B (with Move Members permission) drags User A to voice channel 2
User A disappears from channel 1's member list and appears in channel 2
Users in channel 1 can still hear User A speaking
User A's audio is not heard in channel 2

Details

Environment

Fluxer Canary (web app and desktop)
Hosted instance (api.fluxer.app)

Additional context

This is different from #296 and #715 (which are about the API PATCH endpoint disconnecting users entirely) and #434 (Flatpak/AppImage disconnecting on move). This is a client-side desync where the UI updates but the audio connection doesn't follow.

2 comments

RexSystem 1 vote 20d ago edited originally by @laurentm28 on GitHub OP

This is closely related to #715 (voice channel move leaves the user stuck / LiveKit room transfer never fired server-side). That issue describes a disconnect on move; here the symptom is subtler: the UI moves the user, but the voice stream stays bound to the original channel's LiveKit room, so people in the original channel keep hearing them. Same root cause hypothesis: the destination channel's VOICE_SERVER_UPDATE / LiveKit token handoff never triggers. Worth fixing together. Repro (desktop, canary): User A in voice channel 1 → moderator with Move Members permission drags A to voice channel 2 → A disappears from channel 1 list, appears in channel 2, but A's audio is still heard in channel 1 and not in channel 2.

RexSystem 1 vote 19d ago originally by @laurentm28 on GitHub OP

Additional data point from testing: the bug is not reproducible for every user. With the affected user it behaves like this: the first move (drag to another voice channel) works and the user visibly lands in the destination channel, but on a second consecutive move the user vanishes from the member list while their audio remains audible in the previous channel (and is not heard in the new one). So the failure seems tied to the state accumulated per-session (LiveKit room/connection) rather than to the move action itself — a fresh/healthy client survives the first transfer but a second transfer breaks it.