I have experienced a problem when using the new `a...

# arrow

[strindberg]

I have experienced a problem when using the new `arrow-raise-ktor-server`library in combination with ktor's CachingHeaders plugin. I have not been able to figure out where why the combination causes a stack trace, but it's clear that the combination doesn't work. I have reported it as a bug in in the ktor Youtrack (https://youtrack.jetbrains.com/issue/KTOR-9114/CachingHeaders-in-combination-with-Arrow-causes-stacktrace), but it could well be that the issue is on the Arrow side. I have made a very simple project demonstrating the issue here: https://github.com/strindberg/ktor-sample . I could also file an issue in arrow's github if appropriate.

[Alejandro Serrano.Mena]

it would be great if you could file an issue, indeed thank you color

[strindberg]

Will do.

[strindberg]

https://github.com/arrow-kt/arrow/issues/3784

[phldavies]

postOrRaise will respond with the successful result of the handler, which conflicts with the call the call.respond in the middle of the handler

[phldavies]

The idea behind this is to avoid the ambiguity of intent here:

call.respond(myHappyResponse)
raise(BadRequest("oh no"))

We could protect against this by checking call.isHandled before responding with either the raised or successful result, although I'd want to log a warning of misuse of the API in that case.

[phldavies]

removing the .let { call.respond(it) i.e.

postOrRaise("/error") {
            withError({ errors -> BadRequest(payload = errors) }) {
                getResult()
            }
        }

Should work as expected

[strindberg]

Thank you for the quick reply. This was my response on the github issue: I see the problem, and that makes sense: the lambda should not include a `call.respond(...)`statement. However, I do think this mistake is easy to make, since I (wrongly) understood postOrRaise to work just like post in the routing code, and in regular (non-Arrow) routing, calling call.respond(...) is a common thing to do. Now I will change my code to use it as intended, but some kind of warning is probably warranted.

[strindberg]

By the way, a ktor developer replied that the cachingheaders plugin should check if the response is handled before setting the headers, so there was room for improvement on that end as well.