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.
this post was submitted on 19 Nov 2025
30 points (100.0% liked)
Programming
23517 readers
262 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
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.