Problem with validation when dealing with unions and deep models

[Luzgan]

Sorting

• I'm submitting a ...

  • bug report
  • feature request
  • support request

(I felt bad clicking two of those, but after you will read the case, you will understand why I did that)

• I confirm that I
  • used the search to make sure that a similar issue hasn't already been submit

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

1. 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.
2. 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: [ ]

[Luzgan]

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.

[litoj]

I also have an issue with more complex types which relates to complex object IDs - we have IDs described like:

export type SomeId = `some_str-${number}`

which is something that tsoa isn't able to parse. It would be enough (if not the only option) to have it as a string in the spec.

PS: I think the error message itself is missing a get: GenerateMetadataError: Could not the type of ...

[Luzgan]

Not connected to the main topic here, which considers validation - you are talking here more about generating the documention, lets not mix it here, to avoid confusion.

[blipk]

I also have an issue with more complex types which relates to complex object IDs - we have IDs described like:

export type SomeId = `some_str-${number}`

which is something that tsoa isn't able to parse. It would be enough (if not the only option) to have it as a string in the spec.

PS: I think the error message itself is missing a get: GenerateMetadataError: Could not the type of ...

Encountering the same issue, would be great if we could infer these as just a string