-
-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
possible regression in 0.20.2 affecting routing #1780
Comments
Thanks a lot for this ticket! |
tchoutri
added a commit
that referenced
this issue
Sep 3, 2024
This may have triggered a regression in 0.20.2, and related to #1780
tchoutri
added a commit
that referenced
this issue
Sep 3, 2024
This may have triggered a regression in 0.20.2, and related to #1780
tchoutri
added a commit
that referenced
this issue
Sep 3, 2024
This may have triggered a regression in 0.20.2, and related to #1780
tchoutri
added a commit
that referenced
this issue
Sep 3, 2024
This may have triggered a regression in 0.20.2, and related to #1780
tchoutri
added a commit
that referenced
this issue
Sep 3, 2024
This has triggered a regression in 0.20.2, and closes #1780
Seems like this was introduced in #1750 |
Yep |
theophile-scrive
pushed a commit
to theophile-scrive/servant
that referenced
this issue
Dec 8, 2024
…ant#1781) * Remove strict data from servant{,-server}'s cabal files This has triggered a regression in 0.20.2, and closes haskell-servant#1780 * Restore changelog-d configuration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've noticed a subtle change in behavior with the 0.20.2 release. Often when setting up new routes, I'll implement route handlers as
error "not implemented yet"
initially. Prior to 0.20.2 this worked fine. Existing routes would still work and invoking the unimplemented route would result in the error, as expected. As of 0.20.2, the error is thrown no matter which route is invoked. I was able to reproduce with this minimal example:I expect
/foo
to be successful and/bar
to cause an error, but actually both routes result in the error being throw.I can work around the issue by adding some non-error value prior to the error. e.g.
I suspect something with the way routing is done is less lazy than it used to be, but I'll defer to the maintainers to determine whether this is a bug.
p.s. I love this library. Thanks!
The text was updated successfully, but these errors were encountered: