Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare outage on November 18, 2025 post mortem

blog.cloudflare.com

Post reply on HN
Print view View original

331–340 of 953 posts

Re: Cloudflare outage on November 18, 2025 post mortem

#331

Post by aw1621107 »

echelon wrote: post #320
aw1621107 wrote: post #318

Earlier quoted context omitted.

> It should be limited to use in `unsafe` blocks. That would be a fairly significant expansion of what `unsafe` means in Rust, to put it lightly. Not to mention that I think doing so would not really accomplish anything; marking unwrap() `unsafe` would not "surface `unwrap` usage" or "make any guarantees", as it's perfectly fine for safe functions to contain `unsafe` blocks with zero indication of such in the functio…

> fairly significant expansion of what `unsafe` means in Rust I want an expansion of panic free behavior. We'll never get all the way there due to allocations etc., but this is the class of error the language is intended to fix. This turned into a null pointer, which is exactly what Rust is supposed to quench. I'll go as far as saying I would like to statically guarantee none of my dependencies use the unwrap() metho…

> I want an expansion of panic free behavior.

Sure, and I'd hardly be one to disagree that a first-party method to guarantee no panics would be nice, but marking unwrap() `unsafe` is definitely not an effective way to go about it.

> but this is the class of error the language is intended to fix.

Is it? I certainly don't see any memory safety problems here.

> This turned into a null pointer, which is exactly what Rust is supposed to quench.

There's some subtlety here - Rust is intended to eliminate UB due to null pointer dereferences. I don't think Rust was ever intended to eliminate panics. A panic may still be undesirable in some circumstances, but a panic is not the same thing as unrestricted UB.

> We should be able to design libraries that provably avoid panics to the greatest extent possible.

Yes, this would be nice indeed. But again, marking unwrap() `unsafe` is not an effective way to do so.

dtolnay's no_panic is the best we have right now IIRC, and there are some prover-style tools in an experimental stage which can accomplish something similar. I don't think either of those are polished enough for first-party adoption, though.

Re: Cloudflare outage on November 18, 2025 post mortem

#332

Post by duped »

pdimitar wrote: post #248
duped wrote: post #242

Earlier quoted context omitted.

There's certainly a discipline involved here, but it's usually something like guaranteeing all threads are unwind safe (via AssertUnwindSafe) and logging stack traces when your process keeps dying/can't be started after a fixed number of retries. Which would lead you to the culprit immediately. I'm just pushing back a bit on the idea that unwrap() is unsafe - it's not, and I wouldn't even call it a foot gun. The code…

We don't disagree, my main point was a bit broader and admittedly hijacked the original topic a bit, namely: `unwrap` and `expect` make many Rust devs too comfortable and these two are very tempting mistresses. Using those should be done in an extremely disciplined manner. I agree that there are many legitimate uses but in the production Rust code I've seen this has rarely been the case. People just want to move on a…

Oh for sure. I even think there deserve to be lints like "no code path reachable from main() is unwind-unsafe" which is a heavy hammer for many applications (like one-off CLI utils) but absolutely necessary for something like a long-lived daemon or server that's responsible for critical infrastructure.

Re: Cloudflare outage on November 18, 2025 post mortem

#334

Post by kibwen »

arccy wrote: post #89
ojosilva wrote: post #42

This is the multi-million dollar .unwrap() story. In a critical path of infrastructure serving a significant chunk of the internet, calling .unwrap() on a Result means you're saying "this can never fail, and if it does, crash the thread immediately."The Rust compiler forced them to acknowledge this could fail (that's what Result is for), but they explicitly chose to panic instead of handle it gracefully. This is text…

if you make it easy to be lazy and panic vs properly handling the error, you've designed a poor language

In Rust, `.unwrap()` is nine characters, whereas propagating the Result via `?` is one.

Re: Cloudflare outage on November 18, 2025 post mortem

#337

Post by aw1621107 »

tonyhart7 wrote: post #201
pdimitar wrote: post #179

Earlier quoted context omitted.

There are even lints for this but people get impatient and just override them or fight for them to no longer be the default. As usual: people problem, not a tech problem. In the last years a lot of strides have been made. But people will be people.

and people make mistake at some point machine would be better in coding because well machine code is machine instruction task same like chess, engine is better than human grandmaster because its solvable math field coding is no different

> same like chess, engine is better than human grandmaster because its solvable math field

Might be worth noting that your description of chess is slightly incorrect. Chess technically isn't solved in the sense that the optimal move is known for any arbitrary position is known; it's just that chess engines are using what amounts to a fancy brute force for most of the game and the combination of hardware and search algorithm produces a better result than the human brain does. As such, chess engines are still capable of making mistakes, even if actually exploiting them is a challenge.

Re: Cloudflare outage on November 18, 2025 post mortem

#338

Post by _zagj »

abigailphoebe wrote: post #295
echelon wrote: post #288

Earlier quoted context omitted.

[flagged]

blaming the language is not the way to approach this. if an engineer writes bad code that’s the engineers fault, not the languages. this was bad code that should have never hit production, it is not a rust language issue.

[flagged]

Re: Cloudflare outage on November 18, 2025 post mortem

#339

Post by sophacles »

snoppy45 wrote: post #230

I think you should give me a credit for all the income I lost due to this outage. Who authorized a change to the core infrastructure during the period of the year when your customers make the most income? Seriously, this is a management failure at the highest levels of decision-making. We don't make any changes to our server infrastructure/stack during the busiest time of the year, and neither should you. If there we…

I think you should get exactly what the contract you signed said you'd get. Outages happen in all infrasturture. Planned and unplanned ones both. The SLA and SLO are literal acknowledgements of the fact that and part of the contract for that reason.

Its fair to be upset at their decision making - use that to renegotiate your contract.

Re: Cloudflare outage on November 18, 2025 post mortem

#340

Post by bigstrat2003 »

pyrolistical wrote: post #200
nomel wrote: post #178

Earlier quoted context omitted.

How so? An exception is a value that's given the closest, conceptually appropriate, point that was decided to handle the value, allowing you to keep your "happy path" as clean code, and your "exceptional circumstances" path at the level of abstraction that makes sense. It's way less book-keeping with exceptions, since you, intentionally, don't have to write code for that exceptional behavior, except where it makes se…

Exception is hidden control flow, where as error values are not. That is the main reason why zig doesn’t have exceptions.

Correction: unchecked exceptions are hidden control flow. Checked exceptions are quite visible, and I think that more languages should use them as a result.
Post reply on HN