Can't validate spec (Failed to process specification) without any clue

[gionn]

Launching swagger validator with:

docker run --rm -it -p 8080:8080 -e "REJECT_LOCAL=false" -e "REJECT_REDIRECT=false" --name swagger-validator-v2 swaggerapi/swagger-validator-v2:v2.0.4

having a spec generated with springfox

UI works fine:

• but validator crashes:

curl http://localhost:8080/validator/debug\?url\='https://backend-dev-eng.cloudesire.com/api/v2/api-docs?group=users'
Failed to process specification

[alexpozzi]

I have the same issue and it started happening 2 days ago, without changing the specification we are validating. I tried to debug it but, unfortunately there are no logs except for 500 Internal Server Error - Failed to process specification.

The issue happens only on Open Api v2 specifications, with Open Api v3 specification everything works fine.

Any hint? Don't hesitate to ping me if you need me to provide you more information or if you need me to debug it more.

Thank you :slightly_smiling_face:

[gionn]

Don't hesitate to ping me if you need me to provide you more information or if you need me to debug it more.

I am going almost crazy trying to debug that because it started failing during our yesterday nightly builds without any change to our code/dependencies at all on our side with swaggerapi/swagger-validator:v1.0.6 (been working fine for months), and it's failing consistently on every version I tried between 1.0.6 and 2.0.4.

I was betting that this has something to do with some remote service involved in the process, but running a validation under wireshark inspection didn't give me any clue.

[alexpozzi]

Not a Java developer but it seems that validation schemas are downloaded at runtime https://github.com/swagger-api/validator-badge/blob/master/src/main/java/io/swagger/handler/ValidatorController.java#L60-L64. Tho the validation schemas doesn't seem to have changed lately and validating the same definition that fails locally with the online validator service works.

It would be nice to have the ability to log the exception somewhere to get a little bit more information about the failure https://github.com/swagger-api/validator-badge/blob/master/src/main/java/io/swagger/handler/ValidatorController.java#L88-L92.

[gionn]

validating the same definition that fails locally with the online validator service works.

forgot to mention it, I tested this as well and also for me no problems reported.

[gionn]

:dart:

09:31:05.324 [qtp645994590-59] ERROR i.s.handler.ValidatorController - Failed to process specification
com.github.fge.jsonschema.core.exceptions.ProcessingException: fatal: content at URI "http://swagger.io/v2/schema.json#" is not valid JSON
    level: "fatal"
    uri: "http://swagger.io/v2/schema.json#"
    parsingMessage: "Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')"

    at com.github.fge.jsonschema.core.load.URIManager.getContent(URIManager.java:113) ~[json-schema-core-1.2.8.jar:na]
    at com.github.fge.jsonschema.core.load.SchemaLoader$1.load(SchemaLoader.java:114) ~[json-schema-core-1.2.8.jar:na]
    at com.github.fge.jsonschema.core.load.SchemaLoader$1.load(SchemaLoader.java:108) ~[json-schema-core-1.2.8.jar:na]

~+1 for another thing that randomly broke after remote server enabled https-only access and the http client doesn't follow redirects?~ it looks like redirects are handled

However I tried with:

-    static final String SCHEMA2_URL = "http://swagger.io/v2/schema.json";
+    static final String SCHEMA2_URL = "https://schema.swagger.io/v2/schema.json";

without any luck.

[gionn]

There is hope, tests in the PR I've opened are failing with the same error.

@frantuma any help?

[webron]

@gionn this should be fixed now, can you give it another try?

[gionn]

Yeah, nightly build is green.

Which was the culprit?

[alexpozzi]

Works for me as well. Can you give us more information on what caused the issue?

Thank you!

[webron]

We made an unfortunate mistake of changing the host for the schema file without taking into account the id field in. The change was reverted so the any use of the schema should not be functional.

[alexpozzi]

Thanks for the explanation :slightly_smiling_face: