sahvx655-wq commented on PR #3604: URL: https://github.com/apache/brpc/pull/3604#issuecomment-6381361554
Fair point on the round trip, I'd missed that `ResponseSocketTest` already drives `ProcessRpcResponse` directly. Pushed two cases in `test/brpc_channel_unittest.cpp` under `BaiduAttachmentSizeTest`, each run with `INT32_MIN` and `-1`. The response one follows the `ResponseSocketTest` setup (versioned call id, sending socket bound to the controller) and asserts `ERESPONSE` with the response message and attachment left empty. The request one starts a `Server` on an ephemeral port, hands `ProcessRpcRequest` a message whose socket is one end of a socketpair with the server as `arg`, then reads the baidu_std reply back off the other end and checks the `RpcMeta` carries `EREQUEST` with no body after the meta. I built the suite locally against the unpatched parser first to make sure the cases actually bite: both paths served the payload with `error_code=0`, because the oversized length computed from the negative value just makes `cutn` swallow the whole payload and the body is delivered as if the attachment_size were sane. With the guard in place both report the expected error. The rest of `brpc_channel_unittest` is unaffected; the only failure in my run is `parse_hostname`, which needs the CA file and live DNS and is unrelated. Left the error message as is, since as you say it already prints both the value and the payload size. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
