OpenAPI schema generator doen't handle Zod object without shape on dynamic params

[isaac-sec]

Environment

orpc@1.10.3, node 24.10.0, zod 3.25.51

Reproduction

import { OpenAPIGenerator } from '@orpc/openapi';
import { ZodToJsonSchemaConverter } from '@orpc/zod';
import { oc } from '@orpc/contract';
import { z } from 'zod';

const PlanetIdInputSchema = z.object({
  id: z.string().min(1),
});

const FooSchema = z.object({
  foo: z.number().int().positive(),
});

const PlanetSchema = z.object({
  id: PlanetIdInputSchema.shape.id,
  name: z.string().min(1),
});

const getPlanetContract = oc
  .route({ method: 'GET', path: '/planet/{id}' })
  .input(FooSchema.and(PlanetIdInputSchema))
  .output(PlanetSchema);

const contract = {
  getPlanet: getPlanetContract,
};

const generator = new OpenAPIGenerator({
  schemaConverters: [new ZodToJsonSchemaConverter()],
});

const spec = await generator.generate(contract, {
  info: {
    title: 'Planet API',
    version: '1.0.0',
  },
});

console.log(JSON.stringify(spec, null, 2));

Describe the bug

Using @orpc/opnapi@1.10.3, the generator fails to find existing properties for dynamic params when Zod objects have no shape. This can happen if e.g. intersection (.and()) is used to construct an object, or when using a discriminated union.

Here's the error:

[OpenAPIGenerator] Error occurred while generating OpenAPI for procedure at path: getPlanet
When input structure is "compact", and path has dynamic params, input schema must be an object with all dynamic params as required.

Additional context

No response

Logs

[dosubot]

Hi @isaac-sec! I'm Dosu and I’m helping the orpc team.

This happens because orpc's OpenAPI generator requires the input schema for routes with dynamic path params (like /planet/{id}) to be a plain Zod object with all dynamic params as required fields. When you use .and() (intersection) or discriminated unions, the resulting schema doesn't have a direct "shape" property, so the generator can't extract the required params and throws that error. This is a known limitation—see this discussion.

A recent fix was merged to improve union and intersection schema conversion in the ZodToJsonSchemaConverter, which may help with some related issues, but the core requirement for explicit object shapes for dynamic params remains in orpc@1.10.3 and similar versions citation.

The recommended workaround is to define your input schema as a plain Zod object with the required dynamic params, e.g. z.object({ id: z.string(), foo: z.number().int().positive() }), instead of using .and() or unions for the input. This ensures the generator can correctly map the path params.

If you need to compose schemas, you can manually spread the shapes or use helper functions to build the object, but the final input schema must be a Zod object with all dynamic params as required fields for OpenAPI generation to work.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[dinwwwh]

Why you think this is bug when the message already describe itself? Let's try FooSchema.extend(PlanetIdInputSchema)

[isaac-sec]

This only works in this specific case. Discriminated unions don't have an .extend() method, so you can only use intersection to create new types with them.

For example, assuming FooSchema was defined as follows:

const FooSchema = z.discriminatedUnion('type', [
  z.object({
    type: z.literal("a"),
    foo: z.number().int().positive(),
  }),
  z.object({
    type: z.literal("b"),
    foo: z.number().int().negative(),
  }),
]);

The only way to create an object out of it and PlanetIdInputSchema is using .and().

[dinwwwh]

@isaac-sec OpenAPI spec (not an oRPC's limitation) does not support union/and at this level.

[isaac-sec]

That's understandable, and I don't expect it to be able to express the exact validation schema using JSON schema (I don't really care for it because the oRPC handler will validate the input according to the Zod schema anyway, so worst case the client will send garbage and get back a 400). I do expect it to be able to find the id field when I reference it in the dynamic params, but it fails with any object that is the result of a Zod intersection.

[dinwwwh]

@isaac-sec But how I represent the rest params in open api spec? if you have solution please share it or open an PR.

[isaac-sec]

I'm not sure I understand the issue. The param is present in the object in all of its versions. If I remove the param capture, this is the schema that is generated for the above example:

"allOf": [
  {
    "anyOf": [
      {
        "type": "object",
        "properties": {
          "type": {
            "enum": [
              "a"
            ]
          },
          "foo": {
            "type": "integer",
            "maximum": -1
          }
        },
        "required": [
          "type",
          "foo"
        ]
      },
      {
        "type": "object",
        "properties": {
          "type": {
            "enum": [
              "b"
            ]
          },
          "foo": {
            "type": "integer",
            "minimum": 1
          }
        },
        "required": [
          "type",
          "foo"
        ]
      }
    ]
  },
  {
    "type": "object",
    "properties": {
      "id": {
        "type": "string",
        "minLength": 1
      }
    },
    "required": [
      "id"
    ]
  }
]

The id property is always present, so you should just be able to refer to it as {id}. Am I missing something?

[dinwwwh]

Please show me your full expected OpenAPI spec in this case, and you'll understand why I said this is an OpenAPI spec limitation, @isaac-sec.

---

After thinking again, I believe I can support your case, but the generated schema won’t be 100% correct due to OpenAPI's limitations.