The grpc-json-transcoder filter does not handle errors from streaming backends correctly. I opened this issue to document the current and proposed downstream responses.

Note that #8009 introduced a new convert_grpc_status flag to deduce the HTTP response code and body from the gRPC backend error. This flag introduces another edge case (below).

I think the logic for unary responses is OK. I've only seen these issues with streaming backends.

cc @qiwzhang
cc @ascheglov

Streaming Error with flag set

Configuration: The backend returns a gRPC error via a trailer-only response. The filter is configured with convert_grpc_status=true.

Current Behavior

The filter returns a HTTP 200 OK. The grpc status flag is set in one of the response headers. Assuming that #8312 will be merged in, the response will be [] with content-type application/json.

Proposed Behavior

The filter should return a response that matches the unary case with convert_grpc_status set:

• The HTTP code should match the gRPC status code.
• The response body should be a JSON with the error message.

Streaming Error without flag

Configuration: The backend returns a gRPC error via a trailer-only response. The filter is configured without convert_grpc_status (default behavior).

Current Behavior

Same as above: The filter returns a HTTP 200 OK. The grpc status flag is set in one of the response headers. Assuming that #8312 will be merged in, the response will be [] with content-type application/json.

Proposed Behavior

The filter should return a response that exposes the error:

• The HTTP code should match the gRPC status code.
• The body should be completely empty (""), not an empty JSON array
• Content type should not be set, or it shouldn't matter what it is set to

Other Notes

I would prefer to get #8312 merged in first to fix the content type issue. Please advise on how to handle this, as it may be a breaking change (?)