Skip to content
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

Closed
polina4096 opened this issue Jan 16, 2025 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@polina4096
Copy link

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:

import { Elysia, t } from "elysia";

const app = new Elysia()
  .model({
    "myModel": t.Object({ num: t.Number() })
  })
  .get(
    "/",
    ({ query: { num } }) => {
      console.log({ num })
      return { num };
    },
    {
      query: "myModel"
    }
  )
  .listen(3000);

console.log(
  `🦊 Elysia is running at ${app.server?.hostname}:${app.server?.port}`
);

Send GET /?num=10 and see console.

Request logs { num: "40" } which means that num is a string, however its type inside the query object in the request callback is a number. The LSP also says that the num field inside the query object is a number, 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 be number 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 is string.

Additional information

No response

Have you try removing the node_modules and bun.lockb and try again yet?

Yes.

@polina4096 polina4096 added the bug Something isn't working label Jan 16, 2025
@polina4096
Copy link
Author

I've looked into in more and found out that it's a regression in version 1.2.7. Not sure I have enough time to pinpoint an exact commit right now.

@hoywu
Copy link

hoywu commented Jan 16, 2025

Might be an issue related to #1013.

Commit 57b24c1 is where things changed.

[admin@archlinux elysia]$ git reset --hard 57b24c1^
HEAD is now at 46bb868 :wrench: fix: macro doesn't work with guard
[admin@archlinux elysia]$ bun run --watch example/mytest.ts 
🦊 Elysia is running at localhost:3000
{
  num: 10,
}

[admin@archlinux elysia]$ git reset --hard 57b24c1
HEAD is now at 57b24c1 :wrench: fix: unable to reference schema
[admin@archlinux elysia]$ bun run --watch example/mytest.ts 
🦊 Elysia is running at localhost:3000
{
  num: "10",
}

@SaltyAom SaltyAom self-assigned this Feb 18, 2025
@SaltyAom SaltyAom added pending Should be resolved in next release blocking Blocked by other issues and removed pending Should be resolved in next release labels Feb 18, 2025
@SaltyAom
Copy link
Member

Blocking by sinclairzx81/typebox#1178

@SaltyAom
Copy link
Member

Should be initially fixed by e038104, is going to be published on 1.2.15.

Moved to #1068.

@SaltyAom SaltyAom removed the blocking Blocked by other issues label Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants