fix(no-required-schema-properties-undefined): resolve false positives for bare-required schemas in allOf-composed types

[jeremyfiel]

Problem

The no-required-schema-properties-undefined rule incorrectly reported errors for two valid JSON Schema draft-04 patterns:

1. Bare-required property sub-schema override — a property sub-schema that uses required as a pure presence constraint with no local properties, relying on the property's type definition resolved through a parent allOf.$ref:

   properties:
     personName:
       required: [givenName, familyName]   # no properties block
   allOf:
     - $ref: '#/components/schemas/PersonBase'  # defines personName's type

2. oneOf constraint fragments — oneOf branches that each contain only a required keyword:

   properties:
     communication:
       oneOf:
         - required: [landlines]
         - required: [mobiles]
   allOf:
     - $ref: '#/components/schemas/PersonBase'  # defines communication type

Both are valid per the JSON Schema specification, where required and properties are fully independent keywords.

Solution

Added a hasPropertyInParentContext helper to the rule's enter closure. When the first two checks (local properties and compositionRoot) both fail to find a required property, the helper walks up the parents stack to locate the ancestor schema that contains the current schema as a named property value. It then resolves that ancestor's allOf/anyOf/oneOf siblings and checks whether the property key is defined in any of them — the same hasProperty traversal used elsewhere in the rule.

This approach intentionally preserves misspelling detection: a misspelled key (e.g., giveName vs givenName) still fails the parent-context check and is reported as an error.

Tests

Added 4 new test cases (23 total, all passing):

• should not report bare required when property is defined in parent allOf sibling
• should not report bare required in oneOf branches when property is defined in parent allOf sibling
• should not report bare required in anyOf branches when property is defined in parent allOf sibling
• should report misspelled required property even when parent allOf sibling defines the property

relates to #2320 #2060 #2061

Check yourself

• This PR follows the contributing guide
• All new/updated code is covered by tests
• Core code changed? - Tested with other Redocly products (internal contributions only)
• New package installed? - Tested in different environments (browser/node)
• Documentation update has been considered

Security

• The security impact of the change has been considered
• Code follows company security practices and guidelines

---

Note

Low Risk
Lint-rule behavior change with broad test coverage; reduces false positives without relaxing checks for genuinely undefined or misspelled required keys.

Overview
Fixes false positives in no-required-schema-properties-undefined for valid JSON Schema patterns where a property sub-schema only adds required (or oneOf/anyOf branches with bare required) while the field’s shape comes from a sibling allOf $ref.

The rule now uses hasPropertyInParentContext to walk ancestors, match the property key, and resolve allOf/anyOf/oneOf siblings before flagging a name as undefined; diagnostics use “is undefined” instead of “is not defined.” New tests cover bare required, oneOf/anyOf constraint fragments, and misspellings still reported; v1/v2 docs and a patch changeset document the behavior.

^{Reviewed by Cursor Bugbot for commit 2cc6d1f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 2cc6d1f

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

This PR includes changesets to release 3 packages

Name	Type
@redocly/openapi-core	Patch
@redocly/cli	Patch
@redocly/respect-core	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

[jeremyfiel]

cc @baywet @Drowze would appreciate your feedback if you are using these constructs.

[tatomyr]

Finally got my hands on this. It looks mostly okay for me. However, I'd like to ask you to explore the possibility to solve this without introducing a new concept leveraging the existing logic (if possible).

[tatomyr]

Please do not modify V1 docs.

[tatomyr]

This line actually seems like it should do the same as the previous one, but from a different prospective. Maybe it worth modifying findCompositionRoot / isCompositionChild instead?
Also, the existing code has protection against circular references. Does your code have it? (I haven't found that in your tests.)