Open RobYed opened 7 months ago
Hello there RobYed 👋
Thank you for opening your very first issue in this project.
We will try to get back to you as soon as we can.👀
I see you're using a Partial and a Pick in your interfaces, we have found some other issues when using these utility types: https://github.com/lukeautry/tsoa/issues/1515
For a workaround, I'm betting if you hardcoded the interface without using Pick/Partial that you'd get your validation back
@gcv-epalmer Thanks for your quick response. Yes, you are right. When I turn CreateParticipantRequestDto
into a usual interface, everything works as expected. However, this is something we don't want to do. A fix would be great :)
@RobYed Would you like to open a PR?
@WoH I would like to. However, I do not have any glue of the codebase. Also I don't know what changed from v5.1.1 to v6.0.0. I currently don't have the time to familiarise myself with it :/
I upgraded tsoa from v5.1.1 to v6.0.0 in my project. After that a POST endpoint does not evaluate a (nested)
@pattern
validation annotation anymore and just passes the request to the controller.Sorting
I'm submitting a ...
I confirm that I
Expected Behavior
Given the following
CreateParticipantRequestDto
interface and docs for the request body, I expect tsoa to reject any request which does not contain a validpseudonym
value:Controller method:
If I send this request body, I expect tsoa to reject the request because the
pseudonym
does not match the@pattern
regex.Current Behavior
The
@pattern
validation does not lead to a rejected request if the body is invalid.However, the
@isInt
validation in the above example does work as expected.Possible Solution
Steps to Reproduce
see code snippets above
Context (Environment)
Version of the library: 6.0.0 Version of NodeJS: v20.3.0
Detailed Description
Breaking change?