fix(signal): forward-compat — log+continue on unknown SignalMessage variants

Both sides of the signal channel previously broke their recv loop
on any deserialize error, which meant adding a new variant in one
build silently killed signal connections from peers running an
older build. This bit us during Phase 1 testing: a new client
sending SignalMessage::Reflect to a pre-Phase-1 relay caused the
relay to drop the whole signal connection, which looked like
"Error: not registered" on the next place_call.

Fix:
- New TransportError::Deserialize(String) variant in wzp-proto
  carries serde errors as a distinct category.
- wzp-transport/reliable.rs::recv_signal returns Deserialize on
  serde_json::from_slice failures (was wrapped in Internal).
- wzp-relay/main.rs signal loop matches on Deserialize → warn +
  continue (instead of break).
- desktop/src-tauri/lib.rs recv loop does the same.

Other TransportError variants (ConnectionLost, Io, Internal) still
break the loop — only pure parse failures are recoverable.

This means future SignalMessage variant additions are backward-
compat by construction: older peers will see "unknown variant,
continuing" in their logs while newer peers can keep evolving the
protocol.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Siavash Sameni
2026-04-11 18:13:31 +04:00
parent 8cdf8d486a
commit da08723fe7
4 changed files with 37 additions and 2 deletions

View File

@@ -1307,6 +1307,16 @@ async fn main() -> anyhow::Result<()> {
info!(%addr, "signal connection closed");
break;
}
Err(wzp_proto::TransportError::Deserialize(e)) => {
// Forward-compat: the peer sent a
// SignalMessage variant we don't know
// (newer client, newer federation peer).
// Log and continue — tearing down the
// connection on unknown variants would
// silently kill interop across minor
// protocol version bumps.
warn!(%addr, "signal deserialize (unknown variant?), continuing: {e}");
}
Err(e) => {
warn!(%addr, "signal recv error: {e}");
break;