Cloudflare outage on November 18, 2025 post mortem

Post by richardlblair » Wed, Nov 19, 2025, 3:32 AM UTC

eastdakota wrote: post #95

yen223 wrote: post #57

Earlier quoted context omitted.

I'm curious about how their internal policies work such that they are allowed to publish a post mortem this quickly, and with this much transparency. Any other large-ish company, there would be layers of "stakeholders" that will slow this process down. They will almost always never allow code to be published.

Well… we have a culture of transparency we take seriously. I spent 3 years in law school that many times over my career have seemed like wastes but days like today prove useful. I was in the triage video bridge call nearly the whole time. Spent some time after we got things under control talking to customers. Then went home. I’m currently in Lisbon at our EUHQ. I texted John Graham-Cumming, our former CTO and current…

Post by kibwen » Wed, Nov 19, 2025, 3:33 AM UTC

echelon wrote: post #311

speed_spread wrote: post #264

Earlier quoted context omitted.

Pet peeve: unwrap() should be deprecated and renamed or_panic(). More consistent with the rest of stdlib methods and appropriately scarier.

A lot of stuff should be done about the awful unwrap family of methods. A few ideas: - It should not compile in production Rust code - It should only be usable within unsafe blocks - It should require explicit "safe" annotation from the engineer. Though this is subject to drift and become erroneous. - It should be possible to ban the use of unsafe in dependencies and transitive dependencies within Cargo.

Post by bigstrat2003 » Wed, Nov 19, 2025, 3:35 AM UTC

echelon wrote: post #303

dap wrote: post #301

Earlier quoted context omitted.

I'm not sure if this is serious or not, but to take it at face value: the value of this sort of thing in Rust is not that it prevents crashes altogether but rather that it prevents _implicit_ failures. It forces a programmer to make the explicit choice of whether to crash. There's lots of useful code where `unwrap()` makes sense. On my team, we first try to avoid it (and there are many patterns where you can do this)…

The language semantics do not surface `unwrap` usage or make any guarantees. It should be limited to use in `unsafe` blocks. > There's lots of useful code where `unwrap()` makes sense. On my team, we first try to avoid it (and there are many patterns where you can do this). But when you can't, we leave a comment explaining why it's safe. I would prefer the boiler plate of a match / if-else / if let, etc. to call atte…

Post by echelon » Wed, Nov 19, 2025, 3:38 AM UTC

kibwen wrote: post #323

echelon wrote: post #311

Earlier quoted context omitted.

A lot of stuff should be done about the awful unwrap family of methods. A few ideas: - It should not compile in production Rust code - It should only be usable within unsafe blocks - It should require explicit "safe" annotation from the engineer. Though this is subject to drift and become erroneous. - It should be possible to ban the use of unsafe in dependencies and transitive dependencies within Cargo.

The `unsafe` keyword means something specific in Rust, and panicking isn't unsafe by Rust's definition. Sometimes avoiding partial functions just isn't feasible, and an unwrap (or whatever you want to call the method) is a way of providing a (runtime-checked) proof to the compiler that the function is actually total.

Post by echelon » Wed, Nov 19, 2025, 3:41 AM UTC

bigstrat2003 wrote: post #325

echelon wrote: post #303

Earlier quoted context omitted.

The language semantics do not surface `unwrap` usage or make any guarantees. It should be limited to use in `unsafe` blocks. > There's lots of useful code where `unwrap()` makes sense. On my team, we first try to avoid it (and there are many patterns where you can do this). But when you can't, we leave a comment explaining why it's safe. I would prefer the boiler plate of a match / if-else / if let, etc. to call atte…

Restricting unwrap to unsafe blocks adds negative value to the language. It won't prevent unwrap mistakes (people who play fast and loose with it today will just switch to "foo = unsafe { bar.unwrap() };" instead). And it'll muddy the purpose of unsafe by adding in a use that has nothing to do with memory safety. It's not a good idea.