用一个例子说明 AI 的能力

我是写 C++的，我的 xxx 的应用服务器是自己写的，当然是基于 boost beast ，但也是从 http 流读取 bytes 这个颗粒度开始。今天发现一个问题，就是几个连续的请求会随机出现一个失败。这种情况比较难以复现，并且从 haproxy->xxx 应用服务器存在各种可能性。因为 boost beast 仅支持 http/1.1 ，我禁用了 haproxy 的 http2.0 ，应该不是 http2.0 的问题。然后叫 AI 登场，当然需要给他足够的信息，从生产环境获取 haproxy 的日志和 xxx 应用的日志，然后结合项目的代码，基本上确定了问题所在。

Analyzed session errors and request failures Correlated — this log nails the root cause.

In bbserver_72.log:320-329, the failing /apiv1/users/1/certificates request is preceded by code=5101 what=‘bad method’ and only then you see the downstream {“code”:5018,“what”:“No Session found”}. So 5018 is a symptom, not the root failure, for this case. It lines up exactly with HAProxy: h.log:110767-110770 shows POST …/issues 200 at 10:48:46.977, then GET /apiv1/users/1/certificates returning 500 at 10:48:47.053, while GET …/acme-accounts is 200 at 10:48:47.054. What this pattern strongly suggests:

bbserver sometimes receives “garbage” bytes where it expects the next HTTP request line, so Boost.Beast throws “bad method” (5101). The most common real-world reason is: a previous request with a body was responded to without fully draining its body on a keep-alive connection, so the next request starts mid-body and the method parse explodes. Where to fix (likely):

http_session_monad.hpp:309-333 uses http::async_read_header(…) in parse_header_only() and does not drain any body. If you ever return a response after only parsing headers (auth failure/early exit/etc.) while the client sent a body, you can poison that connection for the next request. If you want, I can implement a robust fix in bbserver (either drain/discard body when header-only is used, or force Connection: close on early-return paths). As a fast mitigation, we can also change HAProxy to close backend connections ( http-reuse never / option http-server-close) to avoid reusing a poisoned keep-alive stream.

其实我大致也是怀疑这个方向，但是从令人眼花缭乱的日志中，根据各个时间点推理出结论。AI 确实已经超越机器。