BUG - OpenAPI Handler fails with discriminator + oneOf for form-urlencoded requests

[LeftoversTodayAppAdmin]

Environment

• Package: @omnigraph/openapi
• GraphQL Mesh Version: latest
• Node Version: 20.16.0

Description

The OpenAPI handler fails to properly handle POST requests with application/x-www-form-urlencoded content type when the request body schema uses discriminator with oneOf structure. The API returns "missing required parameters" error even when all parameters are provided.

Steps to Reproduce

1. Use an OpenAPI spec with the following characteristics:

   • POST endpoint with application/x-www-form-urlencoded request body
   • Request body schema uses oneOf with discriminator
   • Example: USPS OAuth2 token endpoint

2. Configure GraphQL Mesh with the spec:

{
  sourceHandler: loadOpenAPISubgraph('USPS_Token', {
    source: './openapi-spec.yaml',
    operationHeaders: {
      'Content-Type': 'application/x-www-form-urlencoded',
    }
  })
}

3. Call the generated mutation with required parameters

Example OpenAPI Spec Structure

paths:
  /token:
    post:
      requestBody:
        content:
          application/x-www-form-urlencoded:
            schema:
              discriminator:
                propertyName: grant_type
                mapping:
                  client_credentials: '#/components/schemas/ClientCredentials'
              oneOf:
                - $ref: '#/components/schemas/ClientCredentials'

Full spec available: oauth2_3_update.yaml

Expected Behavior

The handler should:

1. Properly serialize form-urlencoded data even with discriminator/oneOf schemas
2. Include all required parameters in the request body
3. Successfully call the API endpoint

Actual Behavior

The API returns: "The request is missing one or more required parameters or is otherwise malformed"

This suggests the parameters are not being properly serialized or sent in the request body.

Workaround

Create a simplified OpenAPI spec without discriminator and oneOf:

paths:
  /token:
    post:
      requestBody:
        required: true
        content:
          application/x-www-form-urlencoded:
            schema:
              type: object
              required:
                - grant_type
                - client_id
                - client_secret
              properties:
                grant_type:
                  type: string
                  enum: [client_credentials]
                client_id:
                  type: string
                client_secret:
                  type: string
                scope:
                  type: string

With this simplified spec, the same mutation works correctly.

Additional Context

• The same OpenAPI spec works correctly with WunderGraph
• Issue specifically occurs with form-urlencoded content type + discriminator pattern
• This is a common pattern in OAuth 2.0 token endpoints

Possible Root Cause

The OpenAPI handler may not be correctly handling the discriminator + oneOf pattern when serializing to application/x-www-form-urlencoded format, possibly:

1. Not flattening the discriminated union properties
2. Not correctly mapping the discriminator value
3. Sending JSON structure instead of form-encoded key-value pairs

Related

• OpenAPI Spec: https://github.com/USPS/api-examples
• OAuth 2.0 Token Endpoint Standard: https://datatracker.ietf.org/doc/html/rfc6749#section-4.4

[ardatan]

Could you test with the alphas here?
#9107 (comment)

[LeftoversTodayAppAdmin]

Tried the alpha and the same error:

{
    "data": {
        "uspsToken_post_token": {
            "error": "invalid_request",
            "error_description": "The request is missing one or more required parameters or is otherwise malformed.",
            "error_uri": "https://www.rfc-editor.org/rfc/rfc6749.html#page-45"
        }
    }
}

Here is the simplified OpenAPI spec that works fine:
USPS_oauth2_simplified.yaml

[LeftoversTodayAppAdmin]

Additional Reproduction Case: Kroger OAuth API

I've encountered the exact same issue with the Kroger OAuth 2.0 API, confirming this is a systemic problem with the OpenAPI handler.

Details

API: Kroger OAuth Token Endpoint
Spec: https://developer.kroger.com/api-products/api/authorization-endpoints-public
Content-Type: application/x-www-form-urlencoded
Issue: Same discriminator + oneOf pattern causing "Unauthorized" errors

Working Direct Call (axios)

await axios.request({
  method: 'POST',
  url: 'https://api.kroger.com/v1/connect/oauth2/token',
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
    'Authorization': 'Basic <base64(client_id:client_secret)>',
  },
  data: {
    grant_type: 'client_credentials',
    scope: 'product.compact',
  },
})

✅ Result: Success

Failed GraphQL Mesh Call (with discriminator spec)

Mesh Config:

{
  sourceHandler: loadOpenAPISubgraph('Kroger_OAuth', {
    source: './kroger-oauth-spec.json',
    operationHeaders: {
      'Content-Type': 'application/x-www-form-urlencoded',
      'Authorization': 'Basic <base64(client_id:client_secret)>',
    }
  })
}

Generated Mutation (Issue #1):

mutation {
  krogerToken_accessToken(
    Authorization: String!  # ❌ Should be in headers, not mutation args
    input: { grant_type: "client_credentials", scope: "product.compact" }
  ) {
    access_token
  }
}

❌ Result: Authorization header defined as required: true in OpenAPI spec is converted to a required mutation argument instead of being handled by operationHeaders

After removing Authorization from spec parameters (Issue #2):

mutation {
  krogerToken_accessToken(
    input: { grant_type: "client_credentials", scope: "product.compact" }
  ) {
    access_token
  }
}

❌ Result: Still 401 Unauthorized (form data not properly serialized due to discriminator)

Workaround Applied

Created simplified spec removing BOTH:

1. Authorization parameter (rely on operationHeaders)
2. discriminator and oneOf (use simple type: object with enum for grant_type)

✅ Result: Success

Issues Identified

1. Header Parameter Conversion Bug: Required header parameters in OpenAPI spec are converted to GraphQL mutation arguments instead of being handled by operationHeaders configuration

2. Form Serialization Bug: The handler doesn't properly serialize application/x-www-form-urlencoded data when discriminator + oneOf is present

Pattern Confirmed

These issues affect OAuth 2.0 token endpoints across multiple APIs:

• USPS OAuth API ✓
• Kroger OAuth API ✓
• Likely affects any API using the standard OAuth 2.0 spec pattern with discriminated grant types

The combination of both bugs makes it impossible to use standard OAuth 2.0 OpenAPI specs without manual simplification.