You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We maintain a multi-file JSON Schema tree (~110 files) that is the source of truth for several generated client packages. Every discriminated union in it crosses a file boundary, so we carry a ~200-line bundling script whose only remaining job is to flatten each spec into one document so mappings resolve. With this fixed, that script goes away and the generator can read our sources directly.
The client generator resolves a cross-file $ref fine, but a discriminator.mapping value pointing at that same file fails with invalid_discriminator_mapping. The effect is that a spec split across multiple files works right up until it uses a discriminated union, which forces consumers to pre-bundle every spec into a single document purely to satisfy mapping resolution.
Thanks for the report. Reproduced with relative and cross-file discriminator.mapping values in several layouts (mapping to a whole sibling file, to a fragment inside a sibling file, a union living in its own file, and a discriminator reached through allOf from another file). The oneOf$ref entries resolved in every case while the mapping values failed.
The cause: mapping values are not JSON Schema keywords, so the schema compiler never resolved them alongside $ref. Planning resolved them afterwards against the rebased, location-independent graph, where relative paths no longer mean anything. Mapping values were also resolved relative to the union schema rather than the document holding the discriminator.
#115 fixes both. Mapping and defaultMapping URI references are now resolved by the compiler exactly like $ref, relative to the document that owns the discriminator, retrieving cross-file targets under the same access rules. A mapping target that cannot be retrieved now produces an invalid_discriminator_mapping diagnostic naming the missing file.
One note on semantics: per OAS 3.1.1, a bare value such as Cat is treated as a schema name, so use ./Cat.json (or ./Cat.json#/...) to point at a file. If your bundling script produces anything the fix does not cover, a small spec tree that still fails would be very welcome.
Activity
tanmaykm commentedon Sep 12, 2026
Thanks for the report. Reproduced with relative and cross-file
discriminator.mappingvalues in several layouts (mapping to a whole sibling file, to a fragment inside a sibling file, a union living in its own file, and a discriminator reached throughallOffrom another file). TheoneOf$refentries resolved in every case while the mapping values failed.The cause: mapping values are not JSON Schema keywords, so the schema compiler never resolved them alongside
$ref. Planning resolved them afterwards against the rebased, location-independent graph, where relative paths no longer mean anything. Mapping values were also resolved relative to the union schema rather than the document holding thediscriminator.#115 fixes both. Mapping and
defaultMappingURI references are now resolved by the compiler exactly like$ref, relative to the document that owns the discriminator, retrieving cross-file targets under the same access rules. A mapping target that cannot be retrieved now produces aninvalid_discriminator_mappingdiagnostic naming the missing file.One note on semantics: per OAS 3.1.1, a bare value such as
Catis treated as a schema name, so use./Cat.json(or./Cat.json#/...) to point at a file. If your bundling script produces anything the fix does not cover, a small spec tree that still fails would be very welcome.fix: resolve cross-file discriminator mapping references (JuliaComput…