Discriminator-based request bodies generate non-compiling convenience overloads

[HavenDV]

Summary

AutoSDK generates non-compiling convenience overloads for request bodies whose schema is a discriminator-based oneOf base type.

The generated client overload writes the discriminator property onto the base request type, but the generated base model does not actually contain that property.

AutoSDK version

0.29.1-dev.28

Minimal repro spec

openapi: 3.0.0
info:
  title: Repro
  version: 1.0.0
paths:
  /pets:
    post:
      operationId: createPet
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/PetRequest'
      responses:
        '200':
          description: ok
          content:
            application/json:
              schema:
                type: string
components:
  schemas:
    PetRequest:
      type: object
      properties:
        type:
          type: string
          default: cat
      discriminator:
        propertyName: type
        mapping:
          cat: '#/components/schemas/CatRequest'
          dog: '#/components/schemas/DogRequest'
      oneOf:
        - $ref: '#/components/schemas/CatRequest'
        - $ref: '#/components/schemas/DogRequest'
    CatRequest:
      type: object
      properties:
        type:
          type: string
          default: cat
        name:
          type: string
      required: [name]
    DogRequest:
      type: object
      properties:
        type:
          type: string
          default: dog
        bark:
          type: boolean
      required: [bark]

Repro steps

1. Run:

   autosdk generate min.yaml --namespace Repro --clientClassName ReproClient --targetFramework net8.0 --output out

2. Build the generated output in a minimal SDK-style project.

Actual result

The generated client contains this overload:

public async Task<string> CreatePetAsync(
    string? type = default,
    CancellationToken cancellationToken = default)
{
    var __request = new Repro.PetRequest
    {
        Type = type,
    };

    return await CreatePetAsync(
        request: __request,
        cancellationToken: cancellationToken).ConfigureAwait(false);
}

But the generated PetRequest model does not contain a Type property:

public partial class PetRequest
{
    [JsonExtensionData]
    public IDictionary<string, object> AdditionalProperties { get; set; } = new Dictionary<string, object>();
}

So the generated project fails to build with:

error CS0117: 'PetRequest' does not contain a definition for 'Type'

Expected result

One of these needs to happen:

• The generated base model should include the discriminator property when convenience overloads assign it.
• Or the convenience overload should not be emitted against the base model.
• Or the overload should instantiate the concrete derived request type instead of the base type.

Extra note

If I add required: [type] to the base schema, AutoSDK changes the helper signature from string? type = default to string type = "cat", which is better, but the generated project still fails to compile for the same reason: the base model still has no Type property.

That means there are two related discriminator issues here:

1. Helper overload generation assumes the base model has the discriminator property.
2. Missing required: [type] also changes the generated helper API shape.

This is currently blocking migration away from a repo-local OpenAPI fixer in tryAGI/Vectara, because AutoSDK can parse the upstream spec but still generates broken code for these discriminator-backed request bodies.