[BUG][C#][generichost] Generic enum converter overrides schema-specific converters for arrays

The converter registration is in the generichost HostConfiguration template at modules/openapi-generator/src/main/resources/csharp/libraries/generichost/HostConfiguration.mustache, where the generic JsonStringEnumConverter is added before the generated enum converters (around lines 39 and 49-50). Start by running the standalone repro (./generate.sh then dotnet run --project Repro.csproj) to see the array payload. Done means the generated client writes integer and wire-string enum arrays correctly, and the repro exits 0 without the --workaround flag. Check #21393 for prior discussion first.

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?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The C# generichost client registers JsonStringEnumConverter before the generated schema-specific enum converters. When serializing enum arrays, the generic converter writes C# member names rather than the wire values declared by the schema.

The standalone reproduction invokes the generated CreateScheduleAsync method and captures the actual outgoing request body with an in-memory HTTP handler. It does not require an API server and does not edit the generated code.

Expected:

{"days":[1,3,5],"day":1,"modes":["manual-mode","auto-mode"]}

Actual:

{"days":["Monday","Wednesday","Friday"],"day":1,"modes":["Manual","Automatic"]}

days is an array of integer enums. modes is an array of string enums whose wire values differ from the generated member names. Both violate the schema. The scalar integer enum day remains numeric and serves as a control.

openapi-generator version

7.26.0, verified as the latest stable release on 2026-10-09. The reproduction pins the official image by digest:

openapitools/openapi-generator-cli:v7.26.0@sha256:a304ddf1e2e5f24f68fa3153568d6174cea4959d09aa8e3db6d526fd0782326d

Tested with .NET SDK 10.0.401 and actual runtime Microsoft.NETCore.App 10.0.12 on macOS 26.6.2 ARM64. System.Text.Json is supplied by that shared framework, with no separate package reference. The generated client references Microsoft.Extensions.Hosting, Microsoft.Extensions.Http, Microsoft.Extensions.Http.Polly, and Microsoft.Net.Http.Headers version 10.0.1.

Also reproduced on latest master using the official published latest Docker image pulled on 2026-10-09:

• Generator version: 7.27.0-SNAPSHOT.
• Image revision: 57164fa6d7642d06e96013e2eb5e842abeb83705, matching GitHub's master head at verification time.
• Image digest: sha256:a56f3a4dfd9979931ea5f3d8f5acff07551b528d4280d4cda32f2102c4bb5fa1.
• Fresh-directory validation and generation exited 0; the default reproduction exited 1 with the same incorrect payload. No workaround was enabled.

This is not claimed to be a new 7.26.0 regression; #21393 previously reported the same ordering problem.

OpenAPI declaration file content or url

Minimal OpenAPI schema in the standalone reproduction repository.

Generation Details

Configuration:

library: generichost
packageName: EnumClient
targetFramework: net10.0
nullableReferenceTypes: true

The repository's generate.sh validates the spec, then runs the pinned generator with:

generate -g csharp -i /local/openapi.yaml -c /local/config.yaml -o /local/generated \
  --global-property apiTests=false,modelTests=false,apiDocs=false,modelDocs=false

No custom templates are used.

Steps to reproduce

Prerequisites: Docker, Bash, and .NET SDK 10.0.401.

git clone https://github.com/alexaka1/repro-OpenAPITools--openapi-generator-integer-enum-arrays.git
cd repro-OpenAPITools--openapi-generator-integer-enum-arrays
./generate.sh
dotnet run --project Repro.csproj

Validation and generation exit with code 0. The console prints the expected and actual request JSON above, followed by:

Integer array matches schema: False
Integer scalar matches schema: True
String array matches schema: False

It intentionally exits with code 1 when the captured body violates the schema.

To regenerate with the exact tested master image and reproduce the failure:

GENERATOR_IMAGE=openapitools/openapi-generator-cli@sha256:a56f3a4dfd9979931ea5f3d8f5acff07551b528d4280d4cda32f2102c4bb5fa1 ./generate.sh
dotnet run --project Repro.csproj

This also exits with code 1 and prints the same mismatch. GENERATOR_IMAGE=openapitools/openapi-generator-cli:latest can be used after pulling that tag to check future master builds.

The separate workaround control was verified against 7.26.0:

dotnet run --project Repro.csproj -- --workaround

The request matches the expected JSON, all three checks print True, and the process exits with code 0. Both commands were verified after generation in a fresh directory.

Related issues/PRs

• #21393 reports the same converter registration order. A maintainer requested a minimal YAML example; this repository provides a complete executable reproduction on 7.26.0 and latest master. I opened this issue for visibility and to provide the verified reproduction. Please feel free to close it as a duplicate of #21393.
• #22917 corrected the generated numeric enum converters' read/write implementation. The ordering problem here prevents those converters from being selected for array elements.

Suggest a fix

Register the generic string-enum converter after the generated schema-specific converters. The version-specific source registers it first in HostConfiguration.mustache, v7.26.0, line 39, before the generated enum converters at lines 49–50. This conflicts with System.Text.Json's first-matching-converter precedence.

The verified workaround uses the existing public configuration API before the options are used:

config.ConfigureJsonOptions(options =>
{
    var converter = options.Converters.OfType<JsonStringEnumConverter>().Single();
    options.Converters.Remove(converter);
    options.Converters.Add(converter);
});

The original failure remains the default repro behavior. The workaround is opt-in and verifies integer arrays, the integer scalar, and string arrays with nontrivial wire values.