They used .unwrap(…) in production, which can escape notice until there’s an error, then it panics. It’s better to always handle the potential error, or at least use ? to pass the error back to the caller.
They also apparently didn’t do any input validation. This is why a faulty config was able to even trigger all of that.
Yep. This was the difference between a silent, recoverable error and a loud failure.
It seems like they’re planning to remove all potential panics based on the end of their article. This would be a good idea considering the scale of the service’s usage.
(Also, for anyone who’s not reading the article, the unwrap caused the service to crash, but wasn’t the source of the issues to begin with. It was just what toppled over first.)
I’ve come to the realization that I’m actually a nerd, because I enjoyed tthat read.
