Bogeychan

The type behaviour is correct. `201` is the status code, no response body value. ```js response: { 201: t.String() // ^ status // ^ body value } ``` Based on...

Use this if you wanna make the last error work: ```ts app.get( "/wrong-200", () => { return { 200: 1 }; }, { response: { 200: t.Object({ 200: t.Number(), }),...

All this kinda follows the OpenAPI `responses` semantic: https://swagger.io/docs/specification/describing-responses/

@aburii thanks for sharing this finding. --- @SaltyAom - The `response` schema with different status codes, as shown above (https://github.com/elysiajs/elysia/issues/785#issuecomment-2297342653), doesn't work anymore. - And returning `number` with `response` schema...

@SaltyAom, here's a quick test case that fails for both `aot: true` and `aot: false`: ```ts // test.test.ts import { Elysia, t } from "elysia"; import { describe, it, expect...

Works for me 💃🏼

Thanks for reporting this finding. You can use `new Elysia({ aot: false })` as a workaround. --- @SaltyAom, it's not just `+` but all characters that have some form of...

Workaround: implement your own `adapter` to use `node:http2` -> https://gist.github.com/bogeychan/39290d2dcf468389c7b82dd8bdc7b2e0

Thanks for reporting this finding. Elysia has built-in support for parsing `application/json`, ..., which is why your body is already used. However, due to (required) access of `ctx` in hooks...

We need to wait until the mentioned Elysia issue is resolved. If other plugins cause similar issues, you can work around it by adding a global parse-hook and manually handling...