Async/suspend support for GrpcExceptionHandlerFunction?

[Hun425]

Problem

We need to call a suspend function inside GrpcExceptionHandlerFunction.apply() to attach a localized error dialog to response trailers. Since apply() returns Status synchronously, we're forced to use runBlocking:

GrpcExceptionHandlerFunction { ctx, status, cause, metadata ->
    val dialog = runBlocking { cause.translateToDialog(locale) } // suspend i18n lookup
    metadata.put(DIALOG_BIN_KEY, dialog.toByteArray())
    status
}

This is risky because InternalGrpcExceptionHandler.handle() runs synchronously on the caller's thread (AbstractServerCall lines 219, 231) — which can be the event loop (e.g. on timeout/cancellation), causing thread starvation.

We also tried wrapping ServerCall.close() via CoroutineServerInterceptor, but the same issue applies — close() is synchronous with no async hook.

Why we can't pre-compute

• The error isn't known until close() time
• This is a cross-cutting concern (interceptor-level), not something we want to leak into every service method
• Framework-level errors (timeouts, cancellations) never pass through our service code

Question

Is there a recommended pattern for async work in the error response path? If not, would there be interest in something like an AsyncGrpcExceptionHandlerFunction returning CompletableFuture<Status>?

UnaryServerCall already uses resFuture.complete() for deferred response completion, so the pipeline seems compatible with async exception handling. Happy to contribute if this is something the project would consider.

Environment

• Armeria 1.33.x, Kotlin 2.2.x, JVM 21, Spring Boot 3.5.x
• gRPC with CoroutineServerInterceptor

[ikhoon]

would there be interest in something like an AsyncGrpcExceptionHandlerFunction returning CompletableFuture?

We need AsyncGrpcExceptionHandlerFunction to support asynchronous functions. I have no objection to adding the API in Armeria.