[wol-soft]

Summary

A rejected update (setter, populate(), additionalProperties()->set() / remove()) left parts of the model state changed: compositions had already recorded their results and applied branch defaults, base validators had already stored additional and pattern properties. The rejected data then influenced later updates (a cached composition result was reused) and the model contained defaults of a branch which doesn't match.

Instead of a rollback per validator (and the SetterRollbackHookInterface of the first version of this PR), every update operation which runs such code now restores the complete model state of a rejected update from a snapshot.

While working on this, several related bugs in the same area were found and fixed here: every update now rejects exactly the data the constructor rejects, and validates only what the update can change.

Changes

Generic rollback of rejected updates

• ModelStateRollback::wrap() (SchemaProcessor\ModelUpdate) wraps an update into snapshot / try / restore-and-rethrow. The helper methods _backupModelState() / _restoreModelState() are added to a class on first use only.
• Wrapped: populate(), additionalProperties()->set() / ->remove(), and each setter path which validates the object (object-level validators, compositions, dependencies of other properties) or runs before-validation hook code. A setter path which only validates the property itself throws before the model state changes and isn't wrapped (no runtime overhead for simple models).
• The snapshot copies each value: get_object_vars() keeps the references linking declared properties into the pattern property storage, so the snapshot would follow later changes.
• populate() uses the same rollback instead of its own list of rolled back attributes (which missed the composition state and branch defaults of properties not part of the update) and catches \Throwable in both error modes.
• The rollbacks of single validators (composition state, additional/pattern property storage) are removed.

Updates validate like the constructor

• The base validation is split: _executeObjectValidators() holds the object-level validators, _executeBaseValidators() keeps a single parameter and calls it and the compositions.
• Setters validate the object-level validators (maxProperties, propertyNames, patternProperties, additionalProperties for a property declared only by a composition branch, ...), the compositions and the schema dependencies of other properties, in the order of the constructor. Before, only setters of properties matching a pattern property validated the object-level validators, as a side effect of a hook which executed all base validators. That pattern property setter hook and the composition setter hook are removed: the setters render the validation themselves (SetterValidationRenderer, passed to the model template like the SchemaHookResolver).
• populate() additionally validates the schema dependencies of the properties it doesn't update.
• remove() validates every composition (after discarding the cached branch results, a removed key can't be passed as updated model data) - a property declared only inside a branch (e.g. the stub of a branch-level required) is stored as additional property and can be removed - and the dependencies of the declared properties against the remaining data. All dependency validation uses the generated _executeDependencyValidators() (added by DependencyValidation; Schema::getDependencyValidators() provides the validators).
• A setter providing the current value of a property which isn't stored yet (null, a default) added the key without validation; it is validated like any added key now.

Only what an update can change is validated

• The validators of an object describe via ObjectUpdateDependentValidatorInterface how an update of a key may change their result (ObjectUpdateDependency: None, AddedKey, Value - in either direction, adding a key may also satisfy minProperties or a property dependency of a branch), also for keys the object doesn't declare. Validators which don't describe it (e.g. custom validators) depend on the value of every key. minProperties, maxProperties and denied properties got dedicated validator classes; DependencyValidatorInterface marks the dependency validators.
• Setters render two paths: adding the key runs everything the key may affect, changing the value of a present key only what depends on the value. A path which validates nothing besides the property itself doesn't snapshot the model state - e.g. the setter of a declared property never validates additionalProperties.
• A composition branch which depends on the values of keys it doesn't declare (e.g. patternProperties, a nested composition) is always evaluated again; a branch which depends on the keys only (e.g. maxProperties, propertyNames, denied additional properties - also via setDenyAdditionalProperties) keeps its cached result unless an update adds a key; other branches keep it as long as none of their properties is updated.
• A true branch has no validators: no update can change its result, it keeps its cached result and doesn't make setters validate the composition. Other branches without a nested schema (e.g. false) depend on the value of every key.
• The validator which only stores additional properties without constraints is extracted into UpdateAdditionalPropertiesValidator so it doesn't count as a constraint.

Branch defaults only for compositions of the schema itself

• The branch default map resolved branch properties on the outer schema by name. For a composition on a named property, a sibling property with the same name was overwritten with the default of the nested branch (getter then failed with a TypeError). Only compositions of the schema itself apply branch defaults now.

A failing composition was reported twice with collected errors

• populate() validated the compositions again per updated property, setters of a property matching a pattern property validated them via both setter hooks. Each update validates each composition once now.

Validation state declared on every mutable model with compositions

• _propertyValidationState was only declared if a setter validates a composition, e.g. a mutable anyOf of untyped object branches created it as (deprecated) dynamic property. Internal properties don't count as branch properties (no empty _getModifiedValues_* helper).

Dependencies of a composition branch only apply with the branch (pre-existing on master)

• A property transferred from a composition branch kept the dependency validators of the branch: the model enforced the dependency of a oneOf/anyOf branch also for data matching another branch, and reported a violated dependency of an allOf branch twice. The transferred property drops them, the composition validates them.

Boolean false branches of compositions of the schema itself (pre-existing on master)

• A false branch (also {"not": true} or {"anyOf": [false]} as branch) of a composition of the schema itself checked the presence of a key named like the class, so it matched any object: e.g. oneOf: [{"required": ["note"]}, false] accepted {} and rejected {"note": "n"}. A root-level allOf: [false] and not: true accepted every object. The object is always present: such a branch now always fails, not: true always rejects.

then: false / else: false with a real if (pre-existing on master)

• Was rejected at generation time as unsatisfiable (SchemaException), but only the values entering the branch are invalid, e.g. "if": {"required": ["kind"]}, "then": false denies kind. The false branch is kept and rejects the values entering it; then: false with else: false emits the always-unsatisfiable warning. Docs (if.rst, allOf/anyOf/oneOf/not.rst) updated.

Bulleted conditional messages with collected errors (follow-up to wol-soft/php-json-schema-model-generator-production#22)

• The production library rendered collected condition / branch errors of a ConditionalException glued to the header line (- Condition: FailedMissing required value for 'kind'); fixed in production#22. The generator test expecting the glued message (ComposedIfTest, collect errors) now expects the bullets.

Merge of master (#193 branch-scoped filters)

• The staging of the filtered values of active branches moved from the removed composition setter hook into the setter rendering: each setter path which validates a composition resets the staging and prepares the values before anything is assigned, the setter applies them once the update succeeded; populate() prepares them after the dependency validation.
• additionalProperties()->set() / ->remove() validate the compositions (see above) and may switch the active branch (e.g. a branch with maxProperties): they reset, prepare and apply the staged filtered values as well. Before, the filtered value of the previous branch was kept, and a value of the newly active branch which the property rejects was accepted.

Related issues found (not fixed here)

• dependencies on a property which is not declared in properties or required are ignored #198 dependencies on a property which is not declared in properties or required are ignored
• Class names of nested composition branches compound per level and exceed the file name limit #199 class names of nested composition branches compound per level and exceed the file name limit (compared with Fix B5: class name compounding and cache key for JsonPointer #152)
• pattern on a property without type is ignored (probably covered by 97ba6db on the unevaluated-properties branch)
• the rendered maxProperties / minProperties count expression violates the generated-code phpcs indentation rule (unchanged by this PR)

Test plan

• ComposedFailedUpdateStateTest: rejected setter/populate after a successful composition, rejection by a second composition after the first one applied a default, branch default on a pattern property (reference kept intact) — both error modes.
• ComposedObjectLevelKeywordUpdateTest: setter, populate, additionalProperties()->set() and ->remove() are rejected with exactly the constructor's exception message for each object-level keyword (incl. $ref branch, implicitly denied additional properties, an additionalProperties schema, collected errors) and leave the model unchanged; branches with declared properties only keep the cache; removal of a property only a branch requires (incl. no stale cached result for a later removal); setter of a property matching a pattern property reports each failing composition once; adding the property a branch dependency requires, or a key a minProperties branch counts, evaluates the branch again; a branch with maxProperties keeps its cache for present keys and the setter of a present key neither validates the composition nor snapshots; adding a key a branch denies (property or pattern property with schema false) is rejected like the constructor, changing a present one doesn't validate; a true branch keeps its cached result and doesn't make setters validate; a false / not: true / nested anyOf: [false] branch is evaluated with every update — both error modes.
• BooleanCompositionSchemaTest: false / not: true / nested anyOf: [false] branches of compositions of the schema itself and root-level allOf: [false] / not: true reject like JSON Schema; then: false / else: false with a real if reject only the values entering the branch (property and object level); then: false + else: false warns and rejects every value — complete messages, both error modes.
• ComposedIfTest: collected conditional errors are rendered as bullets (requires production#22).
• SetterObjectLevelValidationTest: setter and populate violating maxProperties, propertyNames, patternProperties, the schema dependency of another property, or additionalProperties for a property only a branch declares are rejected like the constructor — both error modes; setters of declared properties don't validate additionalProperties; the setter of a present key skips key-only validators; a setter adding a key with the current value is validated.
• AdditionalPropertiesAccessorPostProcessorTest: removal breaking a property / schema dependency is rejected like the constructor and leaves the model unchanged — both error modes.
• FilterCompositionBranchScopeTest: adding / removing an additional property which switches the active oneOf branch adopts the filtered value of the new branch; a switch to a branch whose filtered value the property rejects is rejected like the constructor and keeps the previous branch — both error modes.
• PropertyDependencyTest: a property / schema dependency of a oneOf/anyOf branch doesn't apply to data matching another branch; a violated dependency of an allOf branch is reported once (complete messages).
• ComposedAnyOfTest: mutable object-level anyOf without declared properties creates no dynamic property and no modified values helper.
• SchemaHookTest: state changed by a custom SetterBeforeValidationHookInterface hook is restored; setters without hook code contain no rollback code.
• ComposedOneOfBranchDefaultTest: named-property composition doesn't apply a branch default to a sibling with the same name (constructor and setter).
• Each test added for the review fixes failed before its fix; the skip rules and update dependency classifications were verified by weakening each one (the corresponding tests fail). Moving the update rendering out of RenderHelper doesn't change the generated code (540 generated classes compared before / after, mutable with populate and accessors, both error modes). Full suite on PHP 8.4.27 with production master (incl. Post Processor pre/post execution hooks #22): 3416 tests, 9633 assertions, green except 4 ReferencePropertyTest network-reference cases which couldn't reach raw.githubusercontent.com from the sandbox (same before the changes); all changed lines of the update dependency classes covered (pcov); phpcs clean on changed files.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KhwL6viwijk8NfnTTfufRS
https://claude.ai/code/session_016TbSpXPq3pUmw9Hrh9CfRG

[coveralls]

Coverage Report for CI Build 39961809750

Coverage increased (+0.03%) to 99.21%

Details

• Coverage increased (+0.03%) from the base build.
• Patch coverage: 375 of 375 lines across 32 files are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	8857
Covered Lines:	8787
Line Coverage:	99.21%
Coverage Strength:	605.67 hits per line

---

💛 - Coveralls