[typescript-fetch] to fix incorrect parsing with additional properties#20923
[typescript-fetch] to fix incorrect parsing with additional properties#20923macjohnny merged 4 commits intoOpenAPITools:masterfrom
Conversation
|
refs #20195 |
docs/generators/fsharp-functions.md
Outdated
| |sortModelPropertiesByRequiredFlag|Sort model properties to place required parameters before optional parameters.| |true| | ||
| |sortParamsByRequiredFlag|Sort method arguments to place required parameters before optional parameters.| |true| | ||
| |sourceFolder|source folder for generated code| |OpenAPI/src| | ||
| |sourceFolder|source folder for generated code| |OpenAPI\src| |
There was a problem hiding this comment.
We should revert these - probably because regeneration was done on windows?
There was a problem hiding this comment.
Hello, thank you for the feedback.
I also think it was because of Windows. I'll try using a Linux machine instead to effectively undo my own changes
There was a problem hiding this comment.
Thank you. Done
you can use WSL instead
| {{^isEnumRef}} | ||
| {{^withoutRuntimeChecks}} | ||
| formParams.append('{{baseName}}', new Blob([JSON.stringify({{{dataType}}}ToJSON(requestParameters['{{paramName}}']))], { type: "application/json", })); | ||
| formParams.append('{{baseName}}', new Blob([JSON.stringify({{returnType}}ToJSON(requestParameters['{{paramName}}']))], { type: "application/json", })); |
There was a problem hiding this comment.
can we add a fixture (generated sample) to the repository that shows this change? Or have the samples not been regenerated?
There was a problem hiding this comment.
@joscha Okay, so I retried on WSL and it seems the package-lock.json was the only real change
|
Good Day @joscha , |
joscha
left a comment
There was a problem hiding this comment.
Nice. Will need @macjohnny to merge.
| {{^isEnumRef}} | ||
| {{^withoutRuntimeChecks}} | ||
| formParams.append('{{baseName}}', new Blob([JSON.stringify({{{dataType}}}ToJSON(requestParameters['{{paramName}}']))], { type: "application/json", })); | ||
| formParams.append('{{baseName}}', new Blob([JSON.stringify({{returnType}}ToJSON(requestParameters['{{paramName}}']))], { type: "application/json", })); |
There was a problem hiding this comment.
this seems to be only working when additionalProperties exists
it is causing an issue where the param (paramName here) has it's own schema
for the case shown below, it puts in RequestPayload but instead it should be RequestContext
e.g.
requestBody:
description: entity for which custom field will be added such as fund, deal, asset, investor etc
content:
multipart/form-data:
schema:
$ref: "#/components/schemas/RequestPayload"
...
RequestPayload:
type: object
properties:
context:
$ref: "#/components/schemas/RequestContext"
...
RequestContext:
type: object
properties:
...
There was a problem hiding this comment.
@paras-fundwave thanks for reporting! would you want to send a PR to fix that?
There was a problem hiding this comment.
sure thing!
while I'll familiarise myself with the codebase, can you help confirm the approach I have in mind
we'll need to have 2 outputs (for this line) depending on whether additionalProperties exists
from this PR I can see I'll need to add test-cases too, anything else I'm missing that can help but might not be mentioned in the contributing.md?
There was a problem hiding this comment.
sg, no objections, although i didnt look into the issue in detail
There was a problem hiding this comment.
looks like how datatype is processed has changed too in b/w v7.0.0 and v7.1.0
reverting to dataType is still leads to malformed code - broken v7.1.0 onwards
There was a problem hiding this comment.
Ah, I see. It seems like an inverted mustache section might come in handy. Were you able to spot any other issues around this? Thanks for pointing this out
There was a problem hiding this comment.
Seeing similar issues on 7.14.0 with a discriminated schema where returnType is null and ends up generating invalid code: new Blob([JSON.stringify(ToJSON(...)], ...), dataType generates as expected with new Blob([JSON.stringify(MyDiscriminatedSchemaToJSON(...)], ...)
7.12.0 generates OK, 7.13.0 onwards is broken.
I haven't read up on the original issue fully -- but as the line in question is part of building up the request, using the return type for serializing request parameters seems wrong?
There was a problem hiding this comment.
Diving into the test I don't think the assertion is right.
The schema for the request body is:
"multipart/form-data": {
"schema": {
"type": "object",
"properties": {
"paRes": {
"type": "object",
"additionalProperties": {
"type": "string"
},
"description": "Form sent for Authentication"
}
}
},
"encoding": {
"paRes": {
"style": "form"
}
}
}
ResponseOfString is a schema used as the response:
"responses": {
"200": {
"description": "OK",
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/ResponseOfString"
}
}
}
}
}
The code that gets generated to append the part for the form in the request:
if (requestParameters['paRes'] != null) {
formParams.append('paRes', new Blob([JSON.stringify(ResponseOfStringToJSON(requestParameters['paRes']))], { type: "application/json", }));
}
But that is surely wrong, as ResponseOfString is the response of the operation, not related to the request body?
I have raised a PR to revert: #21542 (FYI @macjohnny)
…roperties (OpenAPITools#20923)" This reverts commit 0becb3f.

Added test
givenObjectHasAdditionalPropertiesWhenGenerateThenIndexSignatureNotUsedToGenerateMethodNameto verify that it works. Also opened the newly generated folder in VSCode and found no syntax errors.@joscha please help review
to close #20195
PR checklist
Commit all changed files.
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
master(upcoming7.x.0minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks)