Can pipeline interceptors handle exceptions thrown further down in the pipeline? I’m trying to add a simple interceptor that retries a call (with a delay) if the call fails. I’d like this to supplement the existing timeout/validation features.

Client or server?

Client.

Nope, sorry. I use the server but haven’t really used the client, so can’t offer much assistance.

Honestly the code is probably similar between each. I’ll take a look.

Sure. You can wrap

proceed

or

proceedWith

method with

try catch

and it will give you the exception!

I had thought that would work, but this fails (maybe I’m misunderstanding the lifecycle here?):

override fun install(feature: RetryOnFailure, scope: HttpClient) {
            scope.receivePipeline.intercept(HttpReceivePipeline.Before) {
                proceedWith(it)
                throw RuntimeException()
            }

            scope.receivePipeline.intercept(HttpReceivePipeline.After) {
                try {
                    proceedWith(it)
                } catch (e: Exception) {
                    println("Hello world")
                    e.printStackTrace()
                }
            }
        }

It should run from

Before

to

After

, so the

Before

will receive the exception thrown in

After

Ah that’s what I had thought. So proceed literally proceeds down the chain then yields back to earlier stages? Makes sense (if i’m understanding correctly)

Exactly.

Ok cool. The only small wrinkle is that validation is handled in an ad-hoc

BeforeReceive

phase. Somehow I’ll need to figure out how to insert even before that.

The

Pipeline

has special methods to insert phase before and after. So you can create a new phase, insert it, and then intercept.

Right, I’ll do that. Sorry for all of the questions 🙂 just one more: Do exceptions span pipelines or are individual pipelines executed separately? I.e. what’s the relationship between

HttpResponsePipeline

and

HttpReceivePipeline

?

It depends on the exception, but usually, they are executed separately. We haven't had any usecases for that, and If you have one you could file an issue.

The only usecase would be to handle timeouts and validation exceptions in a single interceptor. I’ll need to check exactly which pipeline propagates timeouts as I’m unsure right now.