Conversation
|
robert-dean
approved these changes
Jul 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



In order for this to work in Platform, the hbs files in apps/platform need to be updated, which is something I have in a separate branch
Against my better judgement i wanted to support OpenAPI's
oneOfwith a discriminator to enable a multi-type json payload REST endpoint for PgBoss.Our validation code treated oneOf just like anyOf but both oneOf and anyOf were behaving like allOf. Essentially, all the validations for every type were being run.
Previously
allOfmapped tocompositeandanyOfandoneOfmapped tounion. I introducedxorfor oneOf. I also ammended the parsing structure to capture the discriminator object in a flattened, handlerbars friendly way.I deliberately chose to avoid making changes to
validation.expression.hbsand so in order to handle those cases, I hoisted the decision making on parsing those expressions to validation.declaration.hbs which now delegates tosingleunionorxor.discriminantvariants.xorandunionare functionally the same since it is possible foroneOfto map to two differently named but identical schemas that would both pass validation. The behavior is somewhat ill-defined, so I let it use the same formula asoneOf, it greedily checks to see if there is one validation that passes with no errors, and if so it early returns. If no schemas match, all errors are returned joined.for
xor.discriminatoryou will see logic that builds a map of validators and uses the property name to run the correct validator for for the object. It will only return errors for the specific validator.This is what using this looks like in YAML.
This is the validator output: