-
-
Notifications
You must be signed in to change notification settings - Fork 142
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(console): prevent panics if subscriber reports out-of-order times #295
Conversation
tokio-console is now at v0.1.2.
Changes duration_since and unchecked subtractions to assume Duration::ZERO (via Default) if the alternative would be a crash. If the subscriber reports nonsensical data this can result in negative Durations in console's calculations, leading to panics. This has already happened inadvertently. All changed code relates directly to received protobuf data whose validity isn't guaranteed. Relates to tokio-rs#266 (crash) and tokio-rs#289 (fix for root cause)
ff48887
to
15e1618
Compare
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.
overall, this looks good to me --- i left some minor style suggestions, but it's up to you whether you think my suggested code is more readable or not. thanks!
self.stats.total.unwrap_or_else(|| { | ||
since | ||
.duration_since(self.stats.created_at) | ||
.unwrap_or_default() | ||
}) |
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.
nit, take it or leave it: consider
self.stats.total.unwrap_or_else(|| { | |
since | |
.duration_since(self.stats.created_at) | |
.unwrap_or_default() | |
}) | |
self.stats | |
.total | |
.or_else(|| since.duration_since(self.stats.created_at).ok()) | |
.unwrap_or_default() |
Changes duration_since and unchecked subtractions to assume
Duration::ZERO (via Default) if the alternative would be a crash.
If the subscriber reports nonsensical data this can result in negative
Durations in console's calculations, leading to panics. This has already
happened inadvertently. All changed code relates directly to received
protobuf data whose validity isn't guaranteed.
Relates to #266 (crash) and #289 (fix for root cause)
There are a handful of other unwraps/expects I'm not so sure about. These ones looked like pretty clear-cut cases where panicking is possible, undesirable, and clamping to zero is a reasonable response.