Capture extensions on the discriminator

[ChiragAgg5k]

CONTEXT.md states that an extension is "captured on every model that can carry one; never interpreted." Discriminator was the one model that did not follow it — the reader built it from propertyName and mapping and discarded every x- key sitting beside them, so an extension nested inside a discriminator was unreachable from the parsed Specification.

Why it matters

The standard mapping is single-valued: it maps one property value to one schema. A union whose members are distinguished by a combination of properties cannot be expressed with it at all.

Appwrite's spec hits this directly. Five of its attribute models share type: "string" and differ only by format, so mapping can name exactly one of them:

"discriminator": {
  "propertyName": "type",
  "mapping": {
    "string": "#/components/schemas/attributeString"   // only one schema can claim "string"
  },
  "x-mapping": {
    "#/components/schemas/attributeEmail":  { "type": "string", "format": "email" },
    "#/components/schemas/attributeEnum":   { "type": "string", "format": "enum"  },
    "#/components/schemas/attributeUrl":    { "type": "string", "format": "url"   },
    "#/components/schemas/attributeIp":     { "type": "string", "format": "ip"    },
    "#/components/schemas/attributeString": { "type": "string" }
  }
}

A consumer reading only mapping sees 6 of the 10 union members and silently collapses email, enum, url and ip into attributeString. With no way to reach x-mapping, there is no workaround on the consumer side.

The change

Discriminator gains an extensions array, defaulting to [], and the reader passes Value::extensions($value) — the helper it already uses for every other model. Nothing here interprets the extension; it is captured and handed to the consumer, which is the contract the rest of the library follows.

Compatibility

Additive. extensions is a new optional constructor argument in last position, so existing construction sites are unaffected, and the string form of the discriminator keeps defaulting to [].

Tests

Two added to tests/Schema/ReaderTest.php, both verified to fail without the src/ change and pass with it:

• test_discriminator_captures_extensions — x-mapping and x-propertyNames survive alongside propertyName and mapping
• test_discriminator_extensions_default_to_empty — the string form, and the object form with no extensions, both yield []

composer check (lint, pint, rector, phpunit) is green: 44 tests, 363 assertions.

[greptile-apps]

Greptile Summary

The PR preserves x- extension fields found on discriminator objects without interpreting them.

• Adds an optional extensions property to Discriminator.
• Populates it through the shared Value::extensions() parser helper.
• Tests extension preservation and empty defaults for string and object discriminator forms.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The new constructor argument is optional and trailing, all discriminator construction paths remain compatible, and object-form extensions are captured consistently through the existing shared helper.

Important Files Changed

Filename	Overview
src/Model/Schema/Discriminator.php	Adds a backward-compatible trailing extensions constructor property with an empty-array default.
src/Parser/Schema/Reader.php	Captures discriminator extension fields using the same helper used by other parsed models.
tests/Schema/ReaderTest.php	Covers mixed extension values, preservation of standard discriminator fields, and empty defaults for both supported input forms.

_{Reviews (1): Last reviewed commit: "fix: capture extensions on the discrimin..." | Re-trigger Greptile}