-
-
Notifications
You must be signed in to change notification settings - Fork 265
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
Using a model by name in route query leads to type mispatch, yet validation succeeds #1015
Labels
bug
Something isn't working
Comments
I've looked into in more and found out that it's a regression in version |
Might be an issue related to #1013. Commit 57b24c1 is where things changed.
|
Blocking by sinclairzx81/typebox#1178 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What version of Elysia is running?
1.2.10
What platform is your computer?
Darwin 24.3.0 arm64 arm
What steps can reproduce the bug?
A query with a number parameter that has validation using a named model instead of an inline model successfully passes validation, yet the value is actually a string instead.
Minimal repro:
Send
GET /?num=10
and see console.Request logs
{ num: "40" }
which means thatnum
is a string, however its type inside the query object in the request callback is anumber
. The LSP also says that thenum
field inside thequery
object is anumber
, however in reality during execution that is not the case.What is the expected behavior?
It's expected that behavior when supplying the validation model for queries inline or by name is identical. If a model has a query parameter
num: t.Number()
, it type should benumber
and it must be parsed as a number.What do you see instead?
Instead of the expected behavior, only when using a validation model for the query by its name, the real runtime type differs from the reported
number
. Instead it actually isstring
.Additional information
No response
Have you try removing the
node_modules
andbun.lockb
and try again yet?Yes.
The text was updated successfully, but these errors were encountered: