grpc/grpc-go · error

external processor unexpectedly sent request body when reque

Error message

external processor unexpectedly sent request body when request body processing is disabled

What it means

Raised in recvFromProcServerLoop when the external processor's response carries a request_body field but the configured requestBodyMode is modeSkip. The client never asked to process request bodies, so a request-body mutation from the server is a protocol violation and the proc stream is failed via failProcStream.

Source

Thrown at internal/xds/httpfilter/extproc/ext_proc.go:1257

		if err != nil {
			cs.failProcStream(err)
			return
		}
		if resp.GetRequestDrain() {
			// Trigger the drain but continue receiving the drained messages until we
			// get io.EOF.
			cs.triggerBypass()
		}

		if resp.GetImmediateResponse() != nil {
			cs.handleImmediateResponse(resp.GetImmediateResponse(), newStream, opts)
			return
		}

		switch {
		case resp.GetRequestBody() != nil:
			if cs.config.processingModes.requestBodyMode == modeSkip {
				cs.failProcStream(fmt.Errorf("external processor unexpectedly sent request body when request body processing is disabled"))
				return
			}

			streamedResp, ok := cs.validateBodyResponse(resp.GetRequestBody())
			if !ok {
				return
			}
			if streamedResp.GetEndOfStream() {
				cs.discardRequests.Store(true)
			}
			cs.mutatedReqBuffer.Put(streamedResp)

		case resp.GetResponseBody() != nil:
			if cs.config.processingModes.responseBodyMode == modeSkip {
				cs.failProcStream(fmt.Errorf("external processor unexpectedly sent response body when response body processing is disabled"))
				return
			}

View on GitHub (pinned to 03255a9237)

Solutions

1. If you want request-body processing, set processing_mode.request_body_mode to GRPC in the LDS config.
2. If request-body processing is intentionally off, fix the server to never populate request_body in its responses.
3. Enable failure_mode_allow so a misbehaving server bypasses instead of failing user RPCs while you fix it.

Example fix

// before: mode off, server sends request_body
processing_mode:
  request_body_mode: NONE   # server nonetheless returns request_body

// after (option A — enable body processing)
processing_mode:
  request_body_mode: GRPC
// after (option B — stop the server from sending request_body)

// Server-side guard: only emit request_body when negotiated mode allows it.
func maybeRequestBody(mode v3procfilterpb.ProcessingMode_BodySendMode, resp *pb.ProcessingResponse) *pb.ProcessingResponse {
    if mode == v3procfilterpb.ProcessingMode_NONE && resp.GetRequestBody() != nil {
        return nil // do not send; would trigger client-side error 389
    }
    return resp
}

// Client side: failure_mode_allow converts violation -> bypass instead of RPC failure.

When it happens

Trigger: An ext-proc server sends a ProcessingResponse with the request_body oneof set while the filter's processing_mode.request_body_mode is NONE (the default). failProcStream then either tears down the RPC or, with failure_mode_allow, bypasses the processor.

Common situations: Server assumes it should echo/mutate request bodies but the LDS processing_mode leaves request_body_mode at NONE. Server implementation copied from an example that does body mutation without checking the negotiated mode. Mismatch between what the server thinks it can do and the mode the client negotiated in ProtocolConfiguration.

Related errors

• external processor unexpectedly sent response body when resp
• external processor unexpectedly sent response headers when r
• external processor unexpectedly sent response trailers when
• external processor sent response body before sending respons
• external processor sent response body after response trailer

AI-assisted analysis of grpc/grpc-go@03255a9237 (2026-08-07). Data as JSON: /api/errors/8235308050ca7265. Report an issue: GitHub.