validation since 5.2.2 is broken because of [id] field

[eugene-matvejev]

Hello guys, I noticed that with 5.2.2 validation is broken, if ID field is present.

I made side project to demonstrate issue:
Working: eugene-matvejev/symfony-battleship#754
Broken: eugene-matvejev/symfony-battleship#755

json schemas:
https://github.com/eugene-matvejev/battleship-game-api-json-schema

output

tests:behat:
    [behat] ..............F
    [behat] 
    [behat] --- Failed steps:
    [behat] 
    [behat] 001 Example: | POST   | /api/game-init           | game.init.request.1.opponent.json | game.init.response.schema.json    | # tests/behat/suites/api/api.json.validation.against.schema.feature:11
    [behat]       Then validate response against schema "game.init.response.schema.json"                                               # tests/behat/suites/api/api.json.validation.against.schema.feature:7
    [behat]         Unable to resolve URI 'properties/collection' from base '' (JsonSchema\Exception\UriResolverException)
    [behat] 
    [behat] 6 scenarios (5 passed, 1 failed)
    [behat] 15 steps (14 passed, 1 failed)
    [behat] 0m0.39s (22.07Mb)

[erayd]

Thanks for reporting this. However, the current release is 5.2.5 (not 5.2.2), and fixes some known bugs relating to id / $ref.

Do you still encounter this problem with v5.2.5?

[erayd]

@eugene-matvejev I've tested your project with 5.2.5, and can confirm I have replicated the issue within that project.

Could you please post a minimal test case that illustrates where you are encountering this, rather than an entire project?

[erayd]

I have now pinpointed the root cause of this problem.

1. You are loading a schema without a provided URI.
2. Because of (1), the default of `internal://provided-schema' is used.
3. You are then attempting to set a relative id of `properties/collection'.
4. The internal default does not contain a path section, and throws an exception when trying to resolve (3) against it.

This is fixed in #459, and I will backport it for 5.2.6 once merged. I can confirm this fix resolves the issue in your project.

In the meantime, if you add any arbitrary id URI to the top level of your schema document, it will work properly, provided that URI contains a path element.

Note also that your use of the id keyword is extremely strange - you seem to be identifying an awful lot of stuff, but in a way that does not result in a valid location if you were to try dereferencing it. What goal are you trying to achieve with your use of id in those schema documents?