fix: guard nullable 'message' fields in v2 ruleset (issue #863)

[tzh476]

Fixes #863.

When a payload object has a nullable property literally named message, v2-ruleset selectors navigating @property === "message" read .schemaFormat/.oneOf on null and crash validation.

Guard added: !@null && before those reads in ruleset/v2/ruleset.ts (message-examples, payload default/examples, operation-message) and ruleset/v2/functions/messageExamples-spectral-rule-v2.ts.

Verified: the issue example now validates with no error diagnostic; ruleset/validate suite passes (43 suites / 244 tests).

[changeset-bot]

🦋 Changeset detected

Latest commit: 7cead1a

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@asyncapi/parser	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[tzh476]

Hi maintainers - friendly ping: this PR (fixes #863, guard nullable message fields) is ready and MERGEABLE, changeset added, CI/SonarCloud passing; happy to adjust on review. Thank you.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tzh476]

Pushed 7cead1a. This PR changed eight JSONPath expressions but shipped no test, so nothing prevented the guards from being dropped again. That is now fixed.

The new spec drives the public parser.validate() path with the exact document shape from #863 — a schema property literally named message whose example value is null.

Control experiment, guards removed:

TypeError: Cannot read properties of null (reading 'schemaFormat')
→ 2 failed, 1 passed

Guards in place: 3 passed.

One detail worth recording, because it decides what the test has to assert: validate() resolves even on the unfixed code and reports the crash as a diagnostic rather than rejecting. So a "does it throw" assertion passes both before and after the fix and would have guarded nothing — which is exactly the trap I would have fallen into. The two assertions that actually catch the regression are the diagnostic check (/Cannot read properties of null/ must be absent) and the parse() check.

Current state: mergeable: true, no conflicts, SonarCloud quality gate passed.

For context on the fix itself: @property === 'message' also matches a schema property named message, not only a message object, so @.schemaFormat dereferences null. Adding !@null skips null values before the member access — the same guard already present on the sibling oneOf and components.messages expressions in those same arrays, so this makes the set internally consistent rather than introducing a new pattern.

Disclosure: human + LLM collaboration; the numbers above are from runs on this branch.