feat: validate message object examples with spectral schemas

[chrispatmore]

validate message object examples against the schemas in the
object by parsing the schemas using spectral before validating
this proves that the examples are valid.

Related issue(s)
Contributes to: #781

Signed-off-by: Chris Patmore [email protected]

[chrispatmore]

Couple of comments / questions for others

[chrispatmore]

Added the rule in but might not want to do this yet. If not, need a pointer on how to get the tests to run without being in the ruleset

[chrispatmore]

There is code duplication w.r.t to the old rule. I can deal with this after review / thoughts on what's there

[chrispatmore]

has duplication which I can sort out with other comments. and is out of date with base now I think, but any comments on the code are appreciated @jonaslagoni

[jonaslagoni]

I dont think it changed, I just need to find some time to review it ASAP 😅

[chrispatmore]

This will probably need some slight changes / merge conflict resolutions from #786

[jonaslagoni]

@chrispatmore fixed the conflicts, gonna review this once I get back from the gym 🙂

[jonaslagoni]

@chrispatmore would it make sense to add the rule ONLY for when schemaFormat has been defined? i.e. that is the difference between the two spectral rules and they can both live together without having to change that down the road?

Cause that would remove all duplicated code parts and tests and simplify the approach by a mile

[chrispatmore]

Let me take a look. Forcing me to play around with json path expressions again 😉

[chrispatmore]

@jonaslagoni This block still duplicated across the two rules:

function getMessageExamples(message: v2.MessageObject): Array<{ path: JsonPath; value: v2.MessageExampleObject }> {
  if (!Array.isArray(message.examples)) {
    return [];
  }
  return (
    message.examples.map((example, index) => {
      return {
        path: ['examples', index],
        value: example,
      };
    }) ?? []
  );
}

function validate(
  value: unknown,
  path: JsonPath,
  type: 'payload' | 'headers',
  schema: unknown,
  ctx: RulesetFunctionContext,
): ReturnType<typeof schemaFn> {
  return schemaFn(
    value,
    {
      allErrors: true,
      schema: schema as JSONSchema7,
    },
    {
      ...ctx,
      path: [...ctx.path, ...path, type],
    },
  );
}

Not really sure how best to de-depe. Could export from the first one so new once can use, but they're so minor I'm not sure it's worth it

[chrispatmore]

That code smell is false positive, if I remove the as any it won't build

[chrispatmore]

How did removing code increase duplication...

Edit: ah now it's finding the duplicated scenarios in the tests. I think these duplicate usages are valid, because they highlight the difference in behaviour between the two rules

[chrispatmore]

@jonaslagoni thoughts on duplication in the tests?

[jonaslagoni]

What was this change for? 🤔

[chrispatmore]

I think I added this when the same tests were being used for both rules, to ensure no change in behaviour, less relevant now, can remove

[jonaslagoni]

Pretty sure headers cannot be avro 🤔 At least not in v2

[chrispatmore]

No I added the headers to the original tests (schemaFormat not set case) so that It added confidence that header behaviour was maintained across both versions of the rule (before we decided to split the rules)
I can revert this.

Though the new info that headers cannot be v2 means I can simplify the new v2 rule!

[jonaslagoni]

Sorry @chrispatmore I am context-switching like crazy at the moment, might be forgetting stuff...

Do correct me if I say something completely off the chart 😄

[chrispatmore]

No worries @jonaslagoni not in any particular rush. Have adapted to your comments.

The headers cant be avro was interesting, because my rule validating the headers examples against an avro header schema was perfectly happy with it!

Have removed it regardless as, as you say it's not allowed in the spec atm

I expect we will still have quite high duplication in the test spect

[chrispatmore]

Hey @jonaslagoni , I am back from a little break, what are we thinking here?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[jonaslagoni]

👍

[jonaslagoni]

/rtm

[jonaslagoni]

Thanks for the patience @chrispatmore, sorry it took so long 🙏

[asyncapi-bot]

🎉 This PR is included in version 2.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[chrispatmore]

Thanks @jonaslagoni no worries !