wtx-grpc: return the reply instead of having it cleared - #1300
Merged
Conversation
MDA2AV
force-pushed
the
fix/wtx-grpc-empty-reply
branch
from
August 24, 2026 15:53
5ff4489 to
24c7ac8
Compare
Owner
Author
|
/benchmark-multiple --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Owner
Author
|
/benchmark-multiple --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
Benchmark ResultsFrameworks: 2 | Test: ❌
|
MDA2AV
force-pushed
the
fix/wtx-grpc-empty-reply
branch
from
August 24, 2026 16:14
24c7ac8 to
0284f52
Compare
Both gRPC entries answered HTTP/2 200 with content-type application/grpc and
grpc-status 0, and an empty body -- the reply message never went out.
The handler serializes SumReply into state.req.msg_data.body and returns
wtx::Result<()>. In wtx's server framework the handler's return value
finalizes the response, and ResFinalizer for () is:
fn finalize_response(self, req: &mut Request<MsgBufferString>) -> ... {
req.clear();
Ok(StatusCode::Ok)
}
so the framework wiped the buffer the handler had just written. Returning
VerbatimParams instead carries the status and leaves the body alone, which is
what wtx-http2 already does -- it returns VerbatimParams and JsonReply, and
that is why it was never affected.
Not a version regression: 0.48.1 and 0.49.0 behave identically. Worth noting
the pin is inert anyway, since the Dockerfile copies Cargo.toml without
Cargo.lock, so cargo re-resolves on every build; the committed lock says
0.48.1 while the image builds 0.49.0, and the two are inconsistent enough
that cargo --locked refuses outright.
It went unnoticed because h2load counts HTTP/2 200s and never looks at the
gRPC payload, so an empty reply benchmarks perfectly. The entries published
unary-grpc numbers from 2026-07-30; the body assertion only arrived on
2026-08-14 in #1123, and it is what caught this.
Both re-enabled. Validated: wtx-grpc 2/0 (GetSum over h2c, both random
pairs), wtx-grpc-tls 2/0 (GetSum over h2+TLS).
MDA2AV
force-pushed
the
fix/wtx-grpc-empty-reply
branch
from
August 24, 2026 16:21
0284f52 to
ebef65b
Compare
Owner
Author
|
/benchmark-multiple --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
Benchmark ResultsFrameworks: 2 | Test: ✅
|
| Test | Conn | RPS | CPU | Mem | Δ RPS | Δ Mem |
|---|---|---|---|---|---|---|
| unary-grpc | 256 | 3,990,708 | 6379.2% | 727MiB | NEW | NEW |
| unary-grpc | 1024 | 3,620,970 | 6383.3% | 1022MiB | NEW | NEW |
✅ wtx-grpc-tls
| Test | Conn | RPS | CPU | Mem | Δ RPS | Δ Mem |
|---|---|---|---|---|---|---|
| unary-grpc-tls | 256 | 3,688,532 | 5485.4% | 726MiB | NEW | NEW |
| unary-grpc-tls | 1024 | 3,625,918 | 6380.6% | 984MiB | NEW | NEW |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both wtx gRPC entries answered
HTTP/2 200,content-type: application/grpc,grpc-status: 0— with an empty body. The reply message never went out.Cause
The handler serializes
SumReplyintostate.req.msg_data.bodyand returnswtx::Result<()>. In wtx's server framework the handler's return value finalizes the response, andResFinalizer for ()is:So the framework cleared the buffer the handler had filled. Returning
VerbatimParamsinstead carries the status and leaves the body alone:That is exactly what
wtx-http2already does — it returnsVerbatimParamsandJsonReply— which is why that entry was never affected by this.Not a version problem
0.48.1and0.49.0behave identically; I built and probed both. Worth knowing separately: the version pin is inert. The Dockerfile copiesCargo.tomlwithoutCargo.lock, so cargo re-resolves on every build — the committed lock says0.48.1while the image builds0.49.0, and the two are inconsistent enough thatcargo --lockedrefuses outright.Why it went unnoticed
h2loadcounts HTTP/2 200 responses and never inspects the gRPC payload, so an empty reply benchmarks perfectly and publishes RPS.unary-grpcresults publishedHttp2ServerFramework(#1056)The numbers published between July and August were for a server returning no reply body.
Result
Both entries re-enabled and validated:
They need a re-benchmark before publishing again — the old
unary-grpcnumbers were removed with #1291 and should not come back as they were.Related: #1299 restores the
wtx-http2/wtx-wsresults that #1291 deleted alongside these, since all five wtx entries share one result file.