Any reason for this new zod schema generation behavior?

[bombillazo]

Hey, I havent narrowed down the root cause, although I suspect a version change, but why would my generated Zod schemas change using the latest openapi-ts version?:

- export const zPrePayMaxAmtType = zCurAmtType.and(z.object({}));
+ export const zPrePayMaxAmtType = zCurAmtType.and(z.record(z.string(), z.unknown()));

Due to this change, my response validation is failing with Unmergable intersection error. It was working with the previous pattern.

[dosubot[bot]]

The change in your generated Zod schema is likely due to updates in openapi-ts's schema generation logic. Recent versions (notably v0.74.0) introduced a new approach that generates a single, more unified schema per endpoint, which can affect how empty objects and additional properties are represented in Zod. While the docs don't explicitly mention the switch from z.object({}) to z.record(z.string(), z.unknown()), this kind of change can happen as the codegen adapts to better reflect OpenAPI's "free-form object" or "additionalProperties: true" semantics, which z.record(z.string(), z.unknown()) models, whereas z.object({}) models a strictly empty object with no properties allowed see migration guide.

The "Unmergable intersection" error happens because Zod can't intersect a fixed-shape object (like zCurAmtType) with a record type—these schemas are structurally incompatible. This wasn't an issue with z.object({}) because intersecting with an empty object doesn't change the shape.

The Zod plugin is still in beta, so schema generation details may change between versions see plugin docs. If you need the old behavior, you may need to pin your openapi-ts version or adjust your OpenAPI spec to clarify the intended object structure. If your schema should be an empty object, make sure your OpenAPI definition doesn't allow additional properties. If it should allow arbitrary keys, you'll need to update your validation logic to handle the new schema shape.

To reply, just mention @dosu.

---

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

[bombillazo]

@dosu I think this was was introduced with this PR #2287

[mrlubos]

It's so funny how it reacts with 👀

[dosubot[bot]]

You're right that PR #2287 specifically targeted how empty objects with additionalProperties: false are handled inside allOf, aiming to avoid generating problematic index signatures that break polymorphic types. While the docs don't directly confirm that this PR caused the shift from z.object({}) to z.record(z.string(), z.unknown()), the timing and technical context make it likely related. The change you observed suggests the generator now interprets certain schemas as "free-form objects" (matching z.record(z.string(), z.unknown())) rather than strictly empty objects, which can lead to the "Unmergable intersection" error in Zod when combined with fixed-shape objects.

If your schema should be an empty object, double-check your OpenAPI spec to ensure additionalProperties is set as intended. If you expect arbitrary keys, you'll need to update your validation logic to handle the new schema shape. The Zod plugin is still evolving, so schema generation details may continue to change.

To reply, just mention @dosu.

---

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

[mrlubos]

@bombillazo Probably related to changes introduced in #2352

Can you drop your spec there, highlighting the issue?

[bombillazo]

Sorry, this spec I cant share :/ but perhaps once that PR is merged I can try again. Basically the newer versions replace z.object with z.record

[mrlubos]

Not even over email? [email protected]

[bombillazo]

No, unfortunately.

a similar patter I see is this

  SomeType:
      title: SomeType
      allOf:
      - $ref: '#/components/schemas/OtherType'
      - type: object

changes like this

- export const zSomeType = zSomeType.and(z.object({}));
+ export const zSomeType = zSomeType.and(z.record(z.string(), z.unknown()));

[bombillazo]

I can at least confirm that up to v 0.80.2, it is working as before (with the z.object({}), I will freeze to this version until this is fixed. Thanks!