关于看到最近 CF 故障的一些讨论把我整不会了

[pingz]

其实跟我关系不大，这次理论既然人家公开了调查报告，自然会看，至少学习一下。我自己的结论很简单，既然是 fetch_features 它是返回 Result<(), (ErrorFlags, i32)> 那当然不应该用 unwarp ，而是返回一个带 ErrorFlags 的空值。如果加载配置不成功，那就不加载。像 nginx 默认的行为就可以。 fetch_features 它并不是核心功能，无论如何都不应该因为一个边缘设计搞整个系统搞掉。

然后，当我去一些流量比较大的看网站上看相关的讨论，比如说这一篇， https://www.reddit.com/r/rust/comments/1p0susm/comment/nplauce/ 它会说一些在我看来很奇怪的东西：

> From what I can gather, that unwrap wasn't the root cause of this problem.

> Rather, it was the end of a chain of cascading failure.

> Even if this particular error were handled, the series of problems

> that led up to it would have still left things in a questionable state.

如果是一两个也就算了，我看到不止一个类似的评论，不止这一个贴或这一个平台，都是很多点赞。所以我现在真的不会了，想找人交流一下，我的结论到底有什么问题？为什么人有会说这事还有什么根本问题，不是 unwarp 的锅？

[Owen Chia]

cf 的报告里写的很清楚啊，权限变更导致数据库查询结果增多，这个结果是放到一块预申请的内存里的，大小有限，就算这里的检查结果被处理了没有 unwrap 也没法正常工作啊。一开始他们认为是 DDoS 是因为这个查询结果是定时生成的，权限变更还没更新到的地方还能生成的结果正常运行，直到全被错误结果覆盖。

>--
>邮件来自: `CPyUG`华蟒用户组(中文Python技术邮件列表)
>---
>您收到此邮件是因为您订阅了 Google 群组的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
>要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
>如需查看此讨论，请访问 https://groups.google.com/d/msgid/python-cn/c684ea88-16fa-4d4b-9432-c0b0eda685ben%40googlegroups.com。

[pingz]

我不是写 rustlang 的，所以，再请教一下。这里的意思是哪怕换成 map_err 之类的也不行？

[Frost Ming]

主要分歧在于这个错误到底能不能处理，如果能处理，比如你认为fetch_features不是主要功能，出错了忽略可不可以？

而如果不能处理错误，是否Panic都一样，panic反而还更符合软件开发范式一些

我不懂cf这里的业务，所以我也没有个答案

在 2025年11月20日，21:26，pingz <p1ng...@gmail.com> 写道：

我不是写 rustlang 的，所以，再请教一下。这里的意思是哪怕换成 map_err 之类的也不行？

您收到此邮件是因为您订阅了Google群组上的“python-cn(华蟒用户组,CPyUG 邮件列表)”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到python-cn+...@googlegroups.com。
如需查看此讨论，请访问 https://groups.google.com/d/msgid/python-cn/303a21f5-1a3e-4843-999b-984c77df3f11n%40googlegroups.com。

[Owen Chia]

不行的，因为问题不是出在这里啊，他是预分配了一块内存来放那个查询结果生成的东西，查询结果因为数据库权限变化变多了，这块内存肯定是放不下的，看报告里的描述也不像是有判断大小动态申请内存的逻辑，正确的内容被覆盖了，没有东西可以自动回滚，这个 Result<T, E> 已经是在链条最末端了，做不了什么，强行处理也只有两个选择，oom 或者没有东西可以加载。
就像是桥断掉了，检查员发现之后拦起路来发了警告不让车走，这个 unwrap 就像是检查员，他没拦路也走不了，因为桥已经断掉了。

>如需查看此讨论，请访问 https://groups.google.com/d/msgid/python-cn/303a21f5-1a3e-4843-999b-984c77df3f11n%40googlegroups.com。

[pingz]

这里意思就是按 rustlang 的行为，它已经执行了 features.append_with_names() ，把 features 地址给覆盖了？ 类似于 c 语言的 strcpy ？这样虽然可以理解为什么有人会有这种观点。但是 append_with_names 的行为只能是这样吗？

如果不是这里的问题，那报告是刻意忽略掉 append_with_names 的行为？

[pingz]

我一开始读完报告，我是把这部分理解成 nginx -s reload 。那些 feature files 理解成配置文件。nginx 的行为，如果配置文件有问题，那旧的 worker 还是在跑的，不会因为尝试加载错误配置，服务就中断，毕竟 nginx 不像一些支付业务，不需要因为出错就直接掐流量。也许是我假设得太多了。