CHECK_MODE_APPLY_DEFAULTS uses defaults from first "oneOf"|"anyOf" option rather than the one that validates

[dkrieger]

Background

CHECK_MODE_APPLY_DEFAULTS uses defaults from first "oneOf" option rather than the one that validates. The same has been observed with "anyOf", but the test uses "oneOf"

Test

$schemaJson = <<<JSON
{
    "oneOf": [
        {
            "type": "object",
            "properties": {
                "foo": {
                    "type": "object",
                    "properties": {
                        "name": {"enum":["baz"],"default":"baz"},
                        "meta": {"enum":["baz"],"default":"baz"}
                    }
                }
            }
        },
        {
            "type": "object",
            "properties": {
                "foo": {
                    "type": "object",
                    "properties": {
                        "name": {"enum":["bar"],"default":"bar"},
                        "meta": {"enum":["bar"],"default":"bar"}
                    }
                }
            }
        },
        {
            "type": "object",
            "properties": {
                "foo": {
                    "type": "object",
                    "properties": {
                        "name": {"enum":["zip"],"default":"zip"},
                        "meta": {"enum":["zip"],"default":"zip"}
                    }
                }
            }
        }
    ]
}
JSON;

$dataJson = '{"foo": {"name": "bar"}}';
$data = json_decode($dataJson);

$validator = new \JsonSchema\Validator();
$validator->validate(
    $data,
    json_decode($schemaJson),
    \JsonSchema\Constraints\Constraint::CHECK_MODE_APPLY_DEFAULTS
);

echo json_encode($data, JSON_PRETTY_PRINT);

expected output

{
    "foo": {
        "name": "bar",
        "meta": "bar"
    }
}

actual output

{
    "foo": {
        "name": "bar",
        "meta": "baz"
    }
}

getErrors() output

print_r($validator->getErrors());

yields

Array
(
    [0] => Array
        (
            [property] => foo.name
            [pointer] => /foo/name
            [message] => Does not have a value in the enumeration ["zip"]
            [constraint] => enum
            [context] => 1
            [enum] => Array
                (
                    [0] => zip
                )

        )

    [1] => Array
        (
            [property] => foo.meta
            [pointer] => /foo/meta
            [message] => Does not have a value in the enumeration ["zip"]
            [constraint] => enum
            [context] => 1
            [enum] => Array
                (
                    [0] => zip
                )

        )

    [2] => Array
        (
            [property] => foo.name
            [pointer] => /foo/name
            [message] => Does not have a value in the enumeration ["baz"]
            [constraint] => enum
            [context] => 1
            [enum] => Array
                (
                    [0] => baz
                )

        )

    [3] => Array
        (
            [property] => foo.meta
            [pointer] => /foo/meta
            [message] => Does not have a value in the enumeration ["bar"]
            [constraint] => enum
            [context] => 1
            [enum] => Array
                (
                    [0] => bar
                )

        )

    [4] => Array
        (
            [property] =>
            [pointer] =>
            [message] => Failed to match exactly one schema
            [constraint] => oneOf
            [context] => 1
        )

)

[rodehoed]

This one has hit me very hard too :-) After a couple of hours I found this report and I can confirm the incorrect behaviour.

[martin-heralecky]

I stumbled upon this today in v5.3.0 and did some debugging:

The reason this happens is that here, $value is passed by reference and any default values are applied directly to that same variable. This changed variable is then used for all of the other oneOf cases, which causes more problems.

One way to resolve this would be to deep-copy $value each time before passing it to checkUndefined() and then only keep the one $value, that passed the oneOf check (meaning the one that produced no errors).

I think a similar problem occurs with allOf as well as anyOf. All of these contain a foreach that goes through all of the cases, but potentially alters $value with defaults along the way.

Also, #711 is likely to be caused by the same problem.

I'm mentioning @DannyvdSluijs, as you seem to be the maintainer of this project.