Cloudflare's Rust Panic: When .unwrap() Takes Down Half the Internet
Description
A screenshot from a Cloudflare incident postmortem or blog post explaining a production outage caused by Rust code. The text explains: 'When the bad file with more than 200 features was propagated to our servers, this limit was hit -- resulting in the system panicking.' The FL2 Rust code snippet is shown (lines 71-82) with a function 'pub fn fetch_features' that takes '&mut self, input: &dyn BotsInput, features: &mut Features' and returns 'Result<(), (ErrorFlags, i32)>'. The critical lines show checksum manipulation with 'features.checksum &= 0xFFFF_FFFF_0000_0000' and 'features.checksum |= u64::from(self.config.checksum)', followed by the fatal call 'features.append_with_names(&self.config.feature_names).unwrap()' on line 82 (highlighted). The resulting panic message reads: 'thread fl2_worker_thread panicked: called Result::unwrap() on an Err value'. This is a textbook example of why .unwrap() in production Rust code is dangerous -- an unhandled error caused a thread panic which cascaded into 5xx errors
Comments
2Comment deleted
Every Rust developer knows .unwrap() is just a TODO that compiles. Cloudflare found out it's also a TODO that pages the on-call team at 3am
Some developers write code that asks 'what could go wrong?' This developer wrote `.unwrap()` and got a very definitive answer