MessageFailure: simplify toHttpResponse/inHttpResponse #3110
Conversation
|
Not sure why it fails on jdk8/scala-2.13 |
|
That failure is unrelated. It's one I'm hoping to fix with more consistent use of cats-effect-testing. I restarted the build. |
rossabaker
added
breaking
I think the old signature is a leftover from when encoding a body was effectful. This looks like a good simplification.
People can have custom MessageFailures, so this change could ripple outside our repo, but it's unlikely. I can't think of any legitimate uses it would preclude.
This further solidifies the logging that happens as a side-effect. The F I think should wrap the logging and remain otherwise we are trapped in this non RT system. Just my thoughts.
|
@ChristopherDavenport the issue is, it's impossible to do RT-logging using |
| @@ -134,13 +134,12 @@ package object server { | |||
| inDefaultServiceErrorHandler[F, F] | |||
|
|
|||
| def inDefaultServiceErrorHandler[F[_], G[_]]( | |||
| implicit F: Monad[F], | |||
| G: Applicative[G]): Request[G] => PartialFunction[Throwable, F[Response[G]]] = req => { | |||
| implicit F: Monad[F]): Request[G] => PartialFunction[Throwable, F[Response[G]]] = req => { | |||
| case mf: MessageFailure => | |||
| messageFailureLogger.debug(mf)( | |||
| s"""Message failure handling request: ${req.method} ${req.pathInfo} from ${req.remoteAddr | |||
There was a problem hiding this comment.
To @ChristopherDavenport's concern, the relevant logging I see is here, and in JsonDebugger. In both these places, we're returning in F and could compose an effect-tracked log with the response. But I don't see any logging where we're creating these responses, so the effect is more power than we want or need. Maybe I'm missing something, but I think both of you can be made happy?
There was a problem hiding this comment.
Excuse me. This one is missing Sync.
Applicativeconstraints onMessageFailure.inHttpResponselooks redundant because one can't do anything useful with them (given polymorphic context).