You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over here, if you will do what is said in the readme file, you will end up getting very VERY long error message. response.json
This response has 28kB. It goes MUCH MUCH worse if you have bigger models. I had a case, where I got 300MB error message - which can obviously cause OOM for a process and kill the server. Now, I know that having many unions (like in example) additionally with possibility to go deep, is not traditional model. However, if you want to deal with a query like requests, its the model that can happen.
In the response above two things are increasing the error message
The most buggy one I would say, is using stringify and parse when dealing with a deep model. It is causing, that the deeper in the query your error is, number of escaping backslashes is growing very quickly.
Mentioning all possible union options that you are not complying with
Possible Solution
Honestly there are couple things that could be done here. For starters - I dont think that there is a big benefit of mentioning all of the models you are not complying with from the union. However - it might be that I am saying this only because my case causing this useless. But it is worth to mention, that just saying that "x" is an excessive property might be enough (user has openapi documentation after all).
I would be much more interested in being able to turn off validation message creation at all. And instead, receive from tsoa simple information like where user made a mistake (path to property) and what type (excessive property etc).
And definetely I would suggest looking into using JSON.parse and stringify over and over again when dealing with deep models, since this escaping defeats the purpose of an error message, because it gets too big and too unreadable.
Steps to Reproduce
Provided in the readme of an example
Context (Environment)
Version of the library: 6.0.1
Version of NodeJS: 18.16.0
Confirm you were using yarn not npm: [ ]
The text was updated successfully, but these errors were encountered:
Any comments on this one? I am willing to help with it if necessary, since right now I am faced with decision - do something here or step away from TSOA completely on all projects and search for alternative - which is not very pleasant scenario.
Sorting
I'm submitting a ...
(I felt bad clicking two of those, but after you will read the case, you will understand why I did that)
Expected Behavior
Being able to prevent very long errors or have a way to change the way that the message is created.
Current Behavior
I have created a simple example of very problematic behaviour of validation in tsoa:
https://github.com/Luzgan/tsoa-error-example
Over here, if you will do what is said in the readme file, you will end up getting very VERY long error message.
response.json
This response has 28kB. It goes MUCH MUCH worse if you have bigger models. I had a case, where I got 300MB error message - which can obviously cause OOM for a process and kill the server. Now, I know that having many unions (like in example) additionally with possibility to go deep, is not traditional model. However, if you want to deal with a query like requests, its the model that can happen.
In the response above two things are increasing the error message
Possible Solution
Honestly there are couple things that could be done here. For starters - I dont think that there is a big benefit of mentioning all of the models you are not complying with from the union. However - it might be that I am saying this only because my case causing this useless. But it is worth to mention, that just saying that "x" is an excessive property might be enough (user has openapi documentation after all).
I would be much more interested in being able to turn off validation message creation at all. And instead, receive from tsoa simple information like where user made a mistake (path to property) and what type (excessive property etc).
And definetely I would suggest looking into using JSON.parse and stringify over and over again when dealing with deep models, since this escaping defeats the purpose of an error message, because it gets too big and too unreadable.
Steps to Reproduce
Provided in the readme of an example
Context (Environment)
Version of the library: 6.0.1
Version of NodeJS: 18.16.0
The text was updated successfully, but these errors were encountered: