Skip to content

[Http4s:middleware] pre and post error handling - #877

Merged
Baccata merged 8 commits into
series/0.17from
middleware-error-handling
May 30, 2023
Merged

Baccata merged 8 commits into
series/0.17from
middleware-error-handling

Conversation

@yisraelU

Copy link
Copy Markdown
Contributor

I also added utility function for constructing middleware from partial function as I have seen often enough boilerplate to construct a middleware and the default being identity function , i figure this might be a bit cleaner

Comment thread modules/http4s/src/smithy4s/http4s/internals/SmithyHttp4sServerEndpoint.scala Outdated
Comment thread modules/http4s/src/smithy4s/http4s/ServerEndpointMiddleware.scala Outdated
@Baccata

Baccata commented Mar 30, 2023

Copy link
Copy Markdown
Contributor

Let's add additional tests too.

@daddykotex

daddykotex commented May 24, 2023

Copy link
Copy Markdown
Contributor

Following some discussion around this, I've decided to wrap this pull request. I've added a test to make sure that if a user implements a middleware that can raiseError(X) then they can transform this error with flatMapErrors or mapErrors.

Note that if the user uses F.raiseError within flatMapErrors or throw within mapErrors, then the transformation does not happen. This could be solved if we moved the special case into an independent call to recoverWith rather than having two cases in the handleErrorWith

Implemented it as such, it made more sense and it match the previous behavior

@Baccata
Baccata merged commit 3816064 into series/0.17 May 30, 2023
@Baccata
Baccata deleted the middleware-error-handling branch May 30, 2023 10:41
daddykotex added a commit that referenced this pull request Jun 14, 2023
When merging #877, I
introduced a behaviour change that I had not anticipated: the errors
defined in the smithy specs were turned into http response before
users had a chance to react to them in the middleware they provide

this is problematic and this fix reverts that
daddykotex added a commit that referenced this pull request Jun 14, 2023
When merging #877, I
introduced a behaviour change that I had not anticipated: the errors
defined in the smithy specs were turned into http response before
users had a chance to react to them in the middleware they provide

this is problematic and this fix reverts that
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants