Closed LucianBuzzo closed 1 year ago
Does this only affect the OpenAPI v2 generator? I think we should be consistent and also adapt the OpenAPI v3 Spec Generator.
That said, I think https://github.com/lukeautry/tsoa/pull/1469 would also address this.
I'm not sure if you can URI Encode the ref value, but use the unencoded name as the components/definition key, is that specified somewhere?
@WoH I updated my PR to also fix the problem for the v3 generator. AFAICT, what happens is that when the $ref
value is resolved, it decodes the URI, resulting in %24
being decoded to $
- however, because we use the encoded value as a key, it can't find it. The resolution lookup would be for $variable
, but what's in the schema is %24variable
.
By only URI encoding the $ref
value, we avoid this particular issue, without resorting to special case escaping of the keys.
URI encoding only the $ref
URI value is the canonically correct approach as far as I can see!
LGTM
Is the PR merged to version 5.1.1? The issue still exists and has not been solved.
@amrbahaa360 It looks like v5.1.1 was released in February, which won't include this change. A new version needs to be released. @WoH would you be able to cut a new version that includes this fix? v5.1.2 perhaps?
Awesome thanks @WoH !
This fixes an isssue where using
$
in type names leads to invalid OpenAPI specs. This would happen because therefName
property that is used as the object key for refs and to create$ref
attributes is URI encoded on creation, when it only needs to be URI encoded when used in a$ref
attribute.Fixes #1461
Test plan
I had a hard time configuring a unit test to check this behaviour, if anyone can provide some guidance on how to do it please let me know, as the test cases in this repo are hard to follow.