Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tronje Krop
    @tkrop
    Origin is:
    Caused by: java.lang.reflect.InvocationTargetException: null
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_232]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_232]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_232]
    at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_232]
    at de.zalando.zally.core.RulesValidator.invoke(RulesValidator.kt:61) ~[zally-core.jar!/:na]
    ... 99 common frames omitted
Caused by: java.lang.IllegalStateException: node.at("/instance/pointer").textValue() must not be null
    at de.zalando.zally.core.JsonSchemaValidator.toValidationMessage(JsonSchemaValidator.kt:43) ~[zally-core.jar!/:na]
    at de.zalando.zally.core.JsonSchemaValidator.validate(JsonSchemaValidator.kt:36) ~[zally-core.jar!/:na]
    at de.zalando.zally.ruleset.zalando.UseOpenApiRule.validateSchema(UseOpenApiRule.kt:56) ~[zally-ruleset-zalando.jar!/:na]
    ... 104 common frames omitted
    Rob Oxspring
    @roxspring
    Eek. Gotta get to a meeting now, but will take a look this afternoon. Maybe we need to revert and remake the changes more carefully???
    Tronje Krop
    @tkrop
    Testing through on our apis revealed that it is a bug that appears the moment the document started with openapi: ...
    Rob Oxspring
    @roxspring
    Are you seeing this with any openapi spec?
    Tronje Krop
    @tkrop
    I found none, that worked.
    correction I found none openapi 3.0 ... api that worked.
    Rob Oxspring
    @roxspring
    yeah - that's what I was driving at :)
    Tronje Krop
    @tkrop
    2.0 works.
    Rob Oxspring
    @roxspring
    right. that'll contribute to why we're not seeing the problem here. migrating from 2 to 3 is still on our todo list :(
    Tronje Krop
    @tkrop
    damn. I assume it has something to do with the parser configuration, but why are our tests not failing already?
    Rob Oxspring
    @roxspring
    huh. I just tried UseOpenApiRuleTest in IDEA and it failed with this stacktrace.
    ... but I'm sure ./gradle check was passing the other day - and it must have done in CI... does that mean that the subproject tests aren't being run??
    Tronje Krop
    @tkrop
    I agree. It was not obvious that it something was not running. I even thought it was working alright on Friday evening.
    I now see tons of exceptions when compiling/testing.
    Rob Oxspring
    @roxspring
    yeah - gradle shows 996 tests completed, 851 failed, 1 skipped for me !? :(
    Tronje Krop
    @tkrop
    Do we have something that makes the server reload libs or schemas on the fly?
    Rob Oxspring
    @roxspring
    not that I'm aware of
    Tronje Krop
    @tkrop
    same for me.
    we have the travis log, that showed things were running successful.
    Rob Oxspring
    @roxspring
    I think that's whats happening though
    debugging my failing UseOpenApiRuleTest I can see the underlying processing message before the null pointer
    message -> {TextNode@4171} ""content at URI \"http://openapis.org/v3/schema.json#\" is not valid JSON""
    https://www.openapis.org/v3/schema.json does indeed resolve to an html 404 page
    ( i should add that idea also tells me parsingMessage -> {TextNode@4175} ""Unexpected character ('<' (code 60)): expected a valid value (JSON String, Number, Array, Object or token 'null', 'true' or 'false')"" which is why an html page seems relevant)
    Tronje Krop
    @tkrop
    oh ja. I'm currently running the command from the .travis
    it shows the failures but does not fail :)
    Rob Oxspring
    @roxspring
    wtf?
    Tronje Krop
    @tkrop
    what a mess.
    oh, no wrong. it fails.
    lets see in the logs, what Friday happend.
    seems to have worked on Friday.
    Rob Oxspring
    @roxspring
    have we just been unlucky and openapis.org have moved that schema since Friday??
    Tronje Krop
    @tkrop
    that may be the reason.
    Rob Oxspring
    @roxspring
    Feel I have to point out that I did bump json-schema-core to a pre-released version - which could be related to all this https://github.com/zalando/zally/blob/master/server/build.gradle.kts#L67
    Tronje Krop
    @tkrop
    it may even just be temporary down.
    Rob Oxspring
    @roxspring
    true
    but we should be using a bundled version of the schema anyway: https://github.com/zalando/zally/blob/master/server/zally-core/src/main/resources/schemas/openapi-3-schema.json
    Tronje Krop
    @tkrop
    however, it is in general no good idea to go down, if some page is not accessible during startup. we can observe this for old versions too. they deny to start at all.
    Rob Oxspring
    @roxspring
    hmmm - looks like that page has been 404'ing since 2017 (RepreZen/KaiZen-OpenAPI-Editor#339) - so we must be failing to find the local copy
    Tronje Krop
    @tkrop
    so the failure behavior has improved, but the fix was partial.
    Rob Oxspring
    @roxspring
    although I guess it's still possible that the url was 200'ing between 2017 and now
    e.g. earlier on Friday
    Tronje Krop
    @tkrop
    sounds like the right solution preload the resources.
    I agree.
    Rob Oxspring
    @roxspring
    I get the same failures against a checkout of 1-2 month old commits.
    Suggests this whole time we thought we were using the public copy while thinking we were using our own??
    (and suggests it's not a screwup introduced by my recent refactoring!)
    Tronje Krop
    @tkrop
    yes, nothing your recent change is responsible for I would say.
    but if you have an idea where to implement the preload correctly ...
    Tronje Krop
    @tkrop
    Hey lets try this https://github.com/OAI/OpenAPI-Specification/blob/master/schemas/v3.0/schema.json