Configure Armeria to Return gRPC Status Code for Invalid Path

Overview

For an Armeria server that is built with minimal settings and has a simple GrpcService, the server returns only HTTP status code 404 but not any gRPC status such as 12 (UNIMPLEMENTED) when an invalid path is given.

Is there a way to configure the Armeria server so that it returns gRPC status code along with HTTP status?

Examples

Below is an example server that uses http4s-armeria as backend:

import cats.effect.{ExitCode, IO, IOApp}
import org.http4s.armeria.server.ArmeriaServerBuilder

object Main extends IOApp {

  override def run(args: List[String]): IO[ExitCode] = {
    val grpcService = ??? // simple gRPC service defined somewhere else

    ArmeriaServerBuilder[IO]
      .bindHttp(9876, "0.0.0.0")
      .withHttpService(grpcService)
      .resource.useForever.as(ExitCode.Success)
  }
}

Example query command:

curl -v -H 'content-type: application/json' -d '{}' 'http://localhost:9876/io.test.NonExistentService/InvokeInvalidRpc'

In the output, only HTTP status 404 is available but there is no grpc-status in either the response headers or body.

Use Case

For gRPC clients that stick to the protobuf service definitions strictly, it is unlikely for them to send requests with invalid paths.

However, for gRPC servers deployed to AWS and sitting behind an application load balancer, AWS performs health checks against targets at path /AWS.ALB/healthcheck and expects gRPC status 12 (UNIMPLEMENTED) by default if gRPC is used as the protocol version (see reference here).

It’d be great if Armeria server could be configured to return gRPC status (such as 12) for invalid paths.

[ikhoon]

Hello, https://github.com/http4s/http4s-armeria user! 😆 fallbackDecorator would be a good workaround. But I also think we can use the default headers of https://github.com/line/armeria/pull/4520 to set grpc-status 12 for 404 Not Found. Note: A conditional default headers depending on response headers hasn’t been implemented yet. I’d like to add the feature to the PR. Users might set the default headers to ServerBuilder:

Server.builder()
      .setHeader(HttpStatus.NOT_FOUND, "grpc-status", 12)
      // Or dynamically set depending on the status predicate
      .setHeader(status -> ..., "grpc-status", 12)
      // For more than this flexibility, it would be better to
      // use HTTP decorators

[ikhoon]

I tried to implement the feature that dynamically sets/adds the default headers depending on an HTTP status. But it was tricky to handle addHeaders(). If we use a function to store the default value, we don’t know if a header is set by ResponseHeaders or the default headers until it is evaluated.

For that reason, please use the decorator pattern. The following pattern won’t be implemented.

.setHeader(HttpStatus.NOT_FOUND, "grpc-status", 12)
// Or dynamically set depending on the status predicate
.setHeader(status -> ..., "grpc-status", 12)