Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[BUG][csharp][generichost] anyOf with discriminator serializes to {}

Open Beginner friendly
#25,154 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
tooling

Research direction

The serialization logic lives in modules/openapi-generator/src/main/resources/csharp/libraries/generichost/JsonConverter.mustache around lines 380-437. Start from the Write method of the AssetJsonConverter section and compare the oneOf branch (which delegates to the subtype's WriteProperties) with the anyOf branch (which currently writes an empty object). The fix is to make the anyOf branch with discriminator also delegate to the mapped subtype's writer. Verify the change by regenerating the client with the provided schema.json and confirming the wrapper round-trips the original JSON instead of {}.

Written by the indexing model from the issue text.

Description

Bug Report Checklist
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
Description

With the C# generichost generator, an anyOf wrapper with an explicit discriminator mapping reads an object into the correct subtype but serializes the wrapper as {}. Every property is lost, including the discriminator.

The concrete subtype serializes correctly using the same generated converters and serializer options. Changing only the schema composition keyword from anyOf to oneOf makes the wrapper round-trip correctly for both subtypes.

OpenAPI 3.1.1 permits a discriminator alongside anyOf: conditions for using the discriminator object.

Expected input and output:

{"type":"image","id":1,"imageUri":"https://example.com/image.jpg"}

Actual wrapper output:

{}

Verified runtime results:

Composition Subtype Read / concrete subtype write Wrapper write
anyOf + discriminator Image Correct {}
anyOf + discriminator Document Correct {}
oneOf + discriminator Image Correct Original JSON
oneOf + discriminator Document Correct Original JSON

Separate scratch experiments also reproduced the failure with the generated client's own DI serializer options on the macOS host and with OpenAPI 3.0.3. Removing the discriminator in another scratch control made the anyOf wrapper round-trip both subtypes. These extra controls are not part of the checked-in runner. The actual {} output is invalid against Asset, because type is required.

openapi-generator version
  • Official openapitools/openapi-generator-cli:v7.25.0, the latest stable release checked on 2026-10-06.
  • .NET SDK 10.0.401, actual runtime 10.0.12, Ubuntu 24.04.5 LTS / Linux ARM64 for generated-client execution.
  • Loaded System.Text.Json is bundled 10.0.12 from Microsoft.NETCore.App, not a separately referenced JSON package.
  • The .NET orchestration uses Testcontainers 4.15.0; host macOS 26.6.2 / ARM64, Docker daemon 29.8.0 / Linux ARM64.
  • Generated-client direct packages are Microsoft.Extensions.Http, Microsoft.Extensions.Hosting, Microsoft.Extensions.Http.Polly and Microsoft.Net.Http.Headers, all 10.0.1 emitted by the stock generator.

Also reproduced on current master using openapitools/openapi-generator-cli:latest@sha256:1f59ca3f11ec33425a9c76591f261e008953644f476ada37799c595cdd1b2b65. The image reports 7.26.0-SNAPSHOT and its org.opencontainers.image.revision label matches master commit 3501c8a6684e8b4ce4c82d8c9fef7eb1f5fe91b5. A fresh scratch copy using that pinned image, with the same schema, generation settings and harness, returned the same four results and bug summary.

For the master run only, a scratch copy changed the generator image selector to accept the pinned latest@sha256:... reference above. The checked-in runner accepts released version numbers and does not support dotnet run -- latest.

I have not established which release first introduced this behavior.

OpenAPI declaration file content or url

Minimal OpenAPI 3.1.1 input: schema.json.

Asset declares anyOf with references to ImageAsset and DocumentAsset. It requires type and maps image / document discriminator values to those schemas. Each subtype requires its corresponding singleton string enum for type.

The 7.25.0 CLI validator reports No validation issues detected.

Generation Details

The .NET/Testcontainers runner executes the equivalent of:

openapi-generator-cli generate \
  -i schema.json -g csharp -o generated \
  --additional-properties packageName=AnyOfClient,targetFramework=net10.0,library=generichost,nullableReferenceTypes=true,hideGenerationTimestamp=true

The control copies the input and replaces anyOf with oneOf. It changes the package name to OneOfClient so both unmodified generated clients can be compiled together. There are no template overrides, modified generated files, or replacement converters.

Steps to reproduce

Requires .NET 10 and Docker with Linux containers:

git clone https://github.com/alexaka1/repro-openapitools--openapi-generator-anyof-discriminator-serialization.git
cd repro-openapitools--openapi-generator-anyof-discriminator-serialization
dotnet run

The runner generates both clients in the official generator container and executes a .NET harness in the official SDK container. For each subtype it verifies that the wrapper reader populated the subtype, that serializing the concrete subtype preserves the input, and then that serializing the wrapper preserves it.

Observed output:

SUMMARY BUG REPRODUCED: 2/2 anyOf + discriminator cases write {}; concrete subtype writes and both oneOf controls pass.

Require the SUMMARY BUG REPRODUCED line and the four RESULT lines to confirm this bug. The runner returns 1 when it reproduces with the controls passing, 0 when both wrapper compositions work, and 2 for an unexpected harness, generated-client build or control failure. Exit code 1 alone is not evidence: the host dotnet run build can also fail with 1. Docker or generator infrastructure exceptions terminate the process; the missing-image control returned 134 on this macOS host.

The runner saves generated source and logs under artifacts/, including the actual .NET environment and resolved package versions.

Related issues/PRs
  • #24398 reports empty oneOf writers.
  • #23693 reports empty oneOf writers without a discriminator and working writes with a discriminator.
  • #23261 has a similar title but covers a string/null anyOf converter accepting and writing only objects.
  • Open PRs #24674 and #24735 add writers for oneOf without a discriminator. Neither changes the anyOf with discriminator path.

The reports and PRs above concern other union-writing failures. This example uses anyOf with an explicit discriminator and mapping. I did not find an exact existing report in the issue searches.

Suggest a fix

In the generated AssetJsonConverter, Write opens an object, calls an empty WriteProperties, and closes the object. In the oneOf control, Write instead delegates to the selected subtype's generated WriteProperties.

The version-specific 7.25.0 converter template supports this observed difference: the discriminator-writing branch iterates composedSchemas.oneOf, while the anyOf branch is guarded by {{^model.discriminator}}. anyOf with a discriminator reaches neither subtype-writing branch.

The same branch structure remains in the tested master source.

The discriminator path should also handle the mapped anyOf subtype. No generator patch has been tested. The oneOf control is not proposed as a general replacement for anyOf; those compositions can have different validation semantics.

Dominant language
Java
Stars
26.8k
Forks
7.7k
Avg merge
2d 14h
Merged PRs (30d)
139

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenAPITools/openapi-generator

All issues in OpenAPITools/openapi-generator

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.