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
Per the OpenAPI spec, a parameter's type may be described either by schema
or by content (a map with exactly one media type entry), but not both. The
operation compiler's buildProvidedParameters and buildParamDesc only ever
read IOpenApiParameter.Schema, which is null for content-typed parameters.
That null schema was passed straight into DefinitionCompiler.CompileTy,
which eventually dereferences it (schemaObj.Type), throwing a NullReferenceException and failing the build — exactly matching the repro
in #501 (a header parameter declared with content: { application/json: { schema: ... } } } instead of a direct schema).
Fix
Added a resolveParamSchema helper in OperationCompiler.fs that returns param.Schema when present, otherwise falls back to the schema of the sole content entry, otherwise null (preserving prior behaviour for genuinely
schema-less parameters). Used it both when compiling the parameter's
provided type and when building its XML-doc enum description, replacing the
two previous direct reads of current.Schema / p.Schema.
Trade-offs
Only the firstcontent entry is used when a parameter declares more
than one (the OpenAPI 3.x spec restricts content to exactly one entry
for parameters, so this should never occur in practice).
No change to parameters that only ever used schema — behaviour there is
unchanged.
Test Status
✅ Build: dotnet build SwaggerProvider.sln -c Release — 0 errors
(pre-existing warnings only, unrelated to this change)
… of schema (#501)
Per the OpenAPI spec, a parameter's type may be described either by `schema`
or by `content` (a map with a single media type entry), but not both. The
operation compiler only ever read `IOpenApiParameter.Schema`, which is null
for content-typed parameters, so `defCompiler.CompileTy` received a null
schema and threw a NullReferenceException deep inside DefinitionCompiler.
Added `resolveParamSchema` which falls back to the schema of the sole
`content` entry when `Schema` is null, and used it both when compiling the
parameter's provided type and when building its XML doc enum description.
Added a regression test using the exact schema from the issue report.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Critical review finding: the fallback does not preserve the content media type for request serialization. An additional enum-documentation test is also needed.
Fixed in aab6978. I formatted the two files failing CI (src/SwaggerProvider.Runtime/RuntimeHelpers.fs and tests/SwaggerProvider.Tests/RuntimeHelpersTests.fs), then re-ran dotnet fsi build.fsx -t CheckFormat, build, and unit tests successfully.
JSON content is inserted into path placeholders without percent-encoding. A valid value containing /, ?, or # then changes the path structure, query, or fragment instead of remaining part of the parameter (for example, {"x":"a/b?c#d"}). Escape the serialized path value before replacement and cover reserved characters in a regression test.
if isNull param.Content || param.Content.Count = 0 then
None
elif param.Content.Count = 1 then
let kv = param.Content |> Seq.head
Some(kv.Key, kv.Value)
else
let mediaTypes = param.Content.Keys |> String.concat ";"
failwithf
$"Operation '%s{operationId}' parameter '%s{param.Name}' defines content entries [%s{mediaTypes}], but parameters defined via content must contain exactly one media type entry"
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 This PR was created by Repo Assist, an automated AI assistant.
Closes #501
Root cause
Per the OpenAPI spec, a parameter's type may be described either by
schemaor by
content(a map with exactly one media type entry), but not both. Theoperation compiler's
buildProvidedParametersandbuildParamDesconly everread
IOpenApiParameter.Schema, which isnullfor content-typed parameters.That
nullschema was passed straight intoDefinitionCompiler.CompileTy,which eventually dereferences it (
schemaObj.Type), throwing aNullReferenceExceptionand failing the build — exactly matching the reproin #501 (a header parameter declared with
content: { application/json: { schema: ... } } }instead of a directschema).Fix
Added a
resolveParamSchemahelper inOperationCompiler.fsthat returnsparam.Schemawhen present, otherwise falls back to the schema of the solecontententry, otherwisenull(preserving prior behaviour for genuinelyschema-less parameters). Used it both when compiling the parameter's
provided type and when building its XML-doc enum description, replacing the
two previous direct reads of
current.Schema/p.Schema.Trade-offs
contententry is used when a parameter declares morethan one (the OpenAPI 3.x spec restricts
contentto exactly one entryfor parameters, so this should never occur in practice).
schema— behaviour there isunchanged.
Test Status
dotnet build SwaggerProvider.sln -c Release— 0 errors(pre-existing warnings only, unrelated to this change)
dotnet tests/SwaggerProvider.Tests/bin/Release/net10.0/SwaggerProvider.Tests.dll— 575/575 passed (573→575, added a new regression test reproducing the
exact schema from NullReferenceException when generating code for a parameter with no schema #501)
dotnet fantomas --checkon changed files — no violationsenvironment limitation with the test server, unrelated to this change)
Add this agentic workflow to your repo
To install this agentic workflow, run