From 373226a8dcc3f09ad3bd06563b299a027d60b381 Mon Sep 17 00:00:00 2001 From: Henry de Valence Date: Sat, 25 Nov 2023 14:46:15 -0800 Subject: [PATCH] summonerd: don't bail out on bad contribution data The better code pattern for this would be to blanket-handle errors in the method, but at the moment it seems better to just fix the current issue. --- tools/summonerd/src/participant.rs | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tools/summonerd/src/participant.rs b/tools/summonerd/src/participant.rs index 0855b8786b..55753174b6 100644 --- a/tools/summonerd/src/participant.rs +++ b/tools/summonerd/src/participant.rs @@ -98,8 +98,14 @@ impl Participant { tracing::info!("got Contribution message from participant, deserializing..."); let deserialized = tokio::task::spawn_blocking(move || P::deserialize_contribution(contribution)) - .await??; - Ok(Some(deserialized)) + // Only bubble up JoinHandle errors here... + .await?; + // ... so that if there's a deserialization error we return None. + // (ideally this code would be structured differently, so that we didn't have to carefully + // distinguish between different kinds of errors, and just treat any error occurring in the context + // of a participant as a failed contribution, but we don't want to do any more refactoring than + // is necessary to this code.) + Ok(deserialized.ok()) } else { Ok(None) }