Skip to content
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

Merged
merged 2 commits into from
Jun 5, 2024

Conversation

conorsch
Copy link
Contributor

@conorsch conorsch commented Jun 5, 2024

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.

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.
@conorsch conorsch requested a review from cratelyn June 5, 2024 21:54
Copy link
Contributor

@cratelyn cratelyn left a 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())
Copy link
Contributor

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 👍

Copy link
Contributor Author

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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) {
Copy link
Contributor

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 🙂

@conorsch conorsch force-pushed the 101-dont-error-on-message-ids branch from 66466a7 to 3d75d77 Compare June 5, 2024 22:55
@conorsch conorsch marked this pull request as ready for review June 5, 2024 23:14
@conorsch conorsch merged commit 1379ca7 into main Jun 5, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

galileo errors hard if it can't read a message Disable colored logs when no tty
2 participants