Automatic propagation of RequestContext

One of the most complaints from the users is that they are struggling to propagate a RequestContext. Check out this snippet:

@Override
public HttpResponse serve(ServiceRequestContext ctx, HttpRequest req) throws Exception {
    backend1.execute(req).aggregate().handle((aggregatedRes, cause) -> {
        // ctx is not in the thread-local. You should use ctx.makeContextAware() or contextAwareExecutor
        backend2.execute(req)...
    });
    ...             
    return res;
}

If we return a RequestContextAwareCompletebleFuture from aggregate() call, most of the situations are solved because RequestContextAwareCompletebleFuture keeps spwaning the future itself when adding callbacks.

Of course, we cannot propagate the ReqeustContext all of the cases. For example, if a user creates a new CompletableFuture instance and completes it with a value, the RequestContextAwareCompletebleFuture will stop spawning. So he/she has to understand how the propagation works to use Armeria properly.

However, I think Automatic propagation will still reduce the burden of users who are not familiar with the asynchronous server and can lower the entry point.

[anuraaga]

However, I think Automatic propagation will still reduce the burden of users who are not familiar with the asynchronous server and can lower the entry point.

I think you know my opinion 😉

If relying on context and writing an asynchronous server, knowing how context works is a requirement - I find bandaids to be worse since the context bug will inevitably appear, but later in the lifecycle of the codebase and has an even higher chance of affecting production vs development servers. Being confused in the beginning is better than later IMO.

Also, IMO writing asynchronous code effectively basically requires a framework on top of Armeria for a reasonable sized app. I personally know Dagger makes it trivial to solve the context problem completely where it would be harder for a user to make a mistake than do the right thing. I have heard of rxjava users forgetting to subscribe correctly - perhaps enforcing use of something like ArmeriaFlux that automatically subscribes would be harder to forget. I was a little interested in seeing what approaches could help with RxJava but currently have no plans of using it so not sure if I could come up with anything but it seems like a better layer to deal with asynchronous issues than our custom CompletableFuture implementation.

Also just for reference, golang and gRPC both have context and take the approach of no automation at all (note, the Armeria context is a combination of gRPC concepts of Call and Context, only Call is automatic in gRPC). Creating and propagating context is all up to the user. This creates some tedium, and I do think automatically creating context like Armeria does is better, but I do like how it forces users to understand context before using it.

These are my opinions and some reference point, I wouldn’t say no if everyone still felt automatic propagation makes sense 😃

[minwoox]

@minwoox Thanks for the ServiceRequestContext.contextAwareExecutor reference.

It’s not me. Thanks to @anuraaga. 😆