Hit while validating the v10 SDK beta (0.0.0-sdkdev.b00ffbd) against a Music Assistant 2.10 beta server.
What the user sees
Connecting to a server the app used to be paired with produces:
Failed to connect to ws://10.0.2.8:8927/sendspin
…and nothing else. Retrying does the same thing, every time, forever. The only clue is in the log file:
[WRN] Wire framing failure: no PSK matches psk_id N5gdsyzSaufx5beGKzoLzlWOzHilPMr9Fq4uomtdPm0; closing connection
[ERR] Sendspin handshake rejected: no PSK matches psk_id N5gdsyzSaufx5beGKzoLzlWOzHilPMr9Fq4uomtdPm0.
[ERR] Failed to connect to ws://10.0.2.8:8927/sendspin
What it actually means
The server still holds a long-term pairing record for this client; the client's own record store has none. The server opens the Noise handshake with that record's psk_id, the client cannot resolve it, and the handshake fails before any application message is exchanged.
This cannot fix itself, and it cannot be fixed from inside the app. The server is the Noise initiator and picks the PSK, and pairing needs a completed handshake to reach a pairing server/activate. The only remedy is to remove the stale player record on the server and pair again. So the app is currently showing a generic connection error for a condition that (a) will never succeed on retry, and (b) has a precise, actionable fix the user has no way to discover.
Worth noting this is not a rare corner: it happens after any one-sided unpair, a restored server backup, a reinstalled client, or a records file lost for any reason.
What it should do
When a connection fails because of diverged pairing state, say so and say what to do — something like:
This server no longer recognises your pairing.
Music Assistant at 10.0.2.8 has a pairing for this player that this device doesn't have a key for. Remove this player in Music Assistant, then pair again.
Points worth getting right:
- Do not auto-retry it. The SDK already treats it as permanent (no reconnect loop), but the app's own connect/auto-connect paths should not keep re-attempting either — that is what turns one bad handshake into a spinner forever. Worth checking the auto-connect timer here, since
AutoConnectServerId pointed at the failing server and it retried on every scan.
- Offer the way out. A "Pair again" affordance is only useful once the server has dropped its record, so the copy should lead with the server-side step.
- Say which server. With multiple MA instances on the network (this happened with two), naming the host matters — the other server was fine throughout.
Depends on
Sendspin/sendspin-dotnet#190 — the SDK currently collapses this into HandshakeFailureKind.HandshakeRejected alongside unsupported-suite and version-mismatch failures, so there is no non-fragile way to detect it yet. Matching on the message text would work today but would break silently the moment that wording changes; better to wait for the dedicated failure kind and branch on it.
If we want something in front of users before then, the honest interim is to broaden the copy for HandshakeRejected generally ("this server refused the connection — you may need to pair again"), which is true for every current member of that kind without pretending to more precision than we have.
Repro
- Pair the client with a server.
- Remove the client's pairing record without the server removing its own (a one-sided unpair, or delete
%LOCALAPPDATA%\Sendspin for Windows\pairing_records.json).
- Connect to that server.
Hit while validating the v10 SDK beta (
0.0.0-sdkdev.b00ffbd) against a Music Assistant 2.10 beta server.What the user sees
Connecting to a server the app used to be paired with produces:
…and nothing else. Retrying does the same thing, every time, forever. The only clue is in the log file:
What it actually means
The server still holds a long-term pairing record for this client; the client's own record store has none. The server opens the Noise handshake with that record's
psk_id, the client cannot resolve it, and the handshake fails before any application message is exchanged.This cannot fix itself, and it cannot be fixed from inside the app. The server is the Noise initiator and picks the PSK, and pairing needs a completed handshake to reach a pairing
server/activate. The only remedy is to remove the stale player record on the server and pair again. So the app is currently showing a generic connection error for a condition that (a) will never succeed on retry, and (b) has a precise, actionable fix the user has no way to discover.Worth noting this is not a rare corner: it happens after any one-sided unpair, a restored server backup, a reinstalled client, or a records file lost for any reason.
What it should do
When a connection fails because of diverged pairing state, say so and say what to do — something like:
Points worth getting right:
AutoConnectServerIdpointed at the failing server and it retried on every scan.Depends on
Sendspin/sendspin-dotnet#190 — the SDK currently collapses this into
HandshakeFailureKind.HandshakeRejectedalongside unsupported-suite and version-mismatch failures, so there is no non-fragile way to detect it yet. Matching on the message text would work today but would break silently the moment that wording changes; better to wait for the dedicated failure kind and branch on it.If we want something in front of users before then, the honest interim is to broaden the copy for
HandshakeRejectedgenerally ("this server refused the connection — you may need to pair again"), which is true for every current member of that kind without pretending to more precision than we have.Repro
%LOCALAPPDATA%\Sendspin for Windows\pairing_records.json).