-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: don't hard-error on unreadable messages #103
Conversation
For reasons I don't understand, Galileo can fail to create a MessageInfo object from a Message. If that conversion fails, we can't proceed. The unwrap was causing a fatal error; instead, let's just log it and keep going. Closes #101.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✅ in spirit, 💬 in process since this is a draft. nice, simple fix!
let fmt_layer = tracing_subscriber::fmt::layer().with_target(true); | ||
let fmt_layer = tracing_subscriber::fmt::layer() | ||
.with_target(true) | ||
.with_ansi(std::io::stderr().is_terminal()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
logging to stderr feels mildly surprising to me, but i don't have a strong opinion about this 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, subjective, I guess. Putting on my sysadmin hat, I feel strongly that "stdout is for output, stderr is for logging and diagnostics." But in the case of galileo serve
, where the only output is logging, stdout is probably fine. Old habits die hard.
src/handler.rs
Outdated
Ok(m) => m, | ||
Err(e) => { | ||
// We can't return an error, but we also can't proceed, so log the error | ||
// and bare-return to bail out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// and bare-return to bail out. | |
// and early-return to bail out. |
lightly held comment nit, tioli ("take-it-or-leave-it")
@@ -261,7 +261,15 @@ impl EventHandler for Handler { | |||
/// window, then Galileo will respond instructing the user to wait longer. | |||
async fn message(&self, ctx: Context, message: Message) { | |||
// Check whether we should proceed. | |||
let message_info = MessageInfo::new(&message, &ctx).unwrap(); | |||
let message_info = match MessageInfo::new(&message, &ctx) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great 👍
eventually it could be cool to expose a metric counting messages observed / parsed, but that's another item for the rainy day bucket 🙂
66466a7
to
3d75d77
Compare
For reasons I don't understand, Galileo can fail to create a MessageInfo object from a Message. If that conversion fails, we can't proceed. The unwrap was causing a fatal error; instead, let's just log it and keep going. Closes #101.
While I was in there, also patched up the logging, to make the logs easier to read when searching. Therefore closes #87.