Hey everyone. I noticed that RPC transport also re...

# kotlinx-rpc

[Yakiv Yereskovskyi]

Hey everyone. I noticed that RPC transport also rethrows fatal exceptions, like StackOverflow or OOM. Is there an easy way to remap fatals before passing?

[Alexander Sysoev]

Hey! No, there is no way now

[Yakiv Yereskovskyi]

@Alexander Sysoev what do you think about exposing some decorator for invokator in the RPC server API?
https://github.com/Kotlin/kotlinx-rpc/blob/main/krpc/krpc-server/src/commonMain/kotlin/kotlinx/rpc/krpc/server/internal/KrpcServerService.kt#L156

It would unblock the case with passing MDC context and will allow to remap an exception. Like:

val value = decorate {
    when (val invokator = callable.invokator) {
        is RpcInvokator.Method -> {
            callScoped(callId) {
                invokator.call(service, data)
            }
        }

        is RpcInvokator.Field -> {
            invokator.call(service)
        }
    }
}

where decorate in my case can be:

val decorate = { call ->
    try {
        withContext(MDCContext) {
             call()
        }
    } catch ...
}

[Alexander Sysoev]

Thanks for suggestion! It may be so, but right now it is big design decision^ and we don't have capacity to process it in coming releases
But I'll take a note, thanks!

[Yakiv Yereskovskyi]

@Alexander Sysoev I’m sorry for bothering but two issues I mentioned above are kinda blockers to me. Is there a way to open discussion on design? I can implement PR myself, I just need an approve from lib maintainers.

[Alexander Sysoev]

It is very generous from your side! The problem here I see, is that the protocol internal will be undergo complete changes. The current implementation is complicated and hard to maintain. So adding features like this makes it even harder to maintain currently. Right now out priority is better code gen and the gRPC integration for a couple of reasons. They already have stable runtime and we just need to provide better APIs and tooling for it. That doesn't mean that kRPC will get no attention, but it doesn't get all of it. Hopefully, after things are more or less settled with code gen, and gRPC, kRPC will get a full redesign, that will account for all similar requests.
Right now the work on kRPC is done, but it is done around simplifying API (removing footguns), better lifetimes and exception handling. No other work is planned so far.