Repository navigation
Add explicit discriminator mappings for Realtime session configuration unions #566
Description
The Realtime session configuration union is currently represented using oneOf in:
RealtimeClientEventSessionUpdate.properties.sessionRealtimeCreateClientSecretRequest.properties.session
Both referenced schemas require a type property with distinct constant values:
RealtimeSessionCreateRequestGA:type: realtimeRealtimeTranscriptionSessionCreateRequestGA:type: transcription
However, the union does not explicitly declare its discriminator. This prevents some OpenAPI consumers and code generators from recognizing it as a discriminated union.
Could the schema include an explicit discriminator mapping?
session:
type: object
description: |
Update the Realtime session. Choose either a realtime
session or a transcription session.
oneOf:
- $ref: "#/components/schemas/RealtimeSessionCreateRequestGA"
- $ref: "#/components/schemas/RealtimeTranscriptionSessionCreateRequestGA"
discriminator:
propertyName: type
mapping:
realtime: "#/components/schemas/RealtimeSessionCreateRequestGA"
transcription: "#/components/schemas/RealtimeTranscriptionSessionCreateRequestGA"Alternatively, the union could be extracted into a reusable component and referenced from both properties.
This would preserve the existing wire format while making the intended polymorphism explicit for OpenAPI tooling.
Activity
markstuart-oai commentedon Sep 23, 2026
Confirmed in the current published specification: both request unions have distinct required type tags, but no explicit discriminator. The local three-site correction resolves dispatch, but checking generated SDKs found that adding the session.update discriminator renames existing Java union factories, accessors and visitor methods. We should not ship that source-compatibility break as an incidental schema correction. This request-side enhancement remains open while we determine a compatible approach; the independent client-secret response mapping from #549 is proceeding separately. Neither request mapping is claimed published or fixed.
markstuart-oai commentedon Sep 23, 2026
Update: a compatibility-preserving attempt was tested and rejected before publication. Removing the new request discriminator metadata from the SDK projection was not sufficient: the current generator still retains its original provenance, changing Java union factories/accessors/visitor methods and Java/Python/Ruby dispatch.
The two public mappings themselves preserve the existing wire shapes, but we should not introduce those SDK changes incidentally. This issue remains open while that generator compatibility behavior is addressed. No request-side fix is claimed shipped; the independent response mapping remains fixed.