Fetch base directory URI from Registry about json-everything

[gregsdennis]

Thanks for the report. I'll have to check what changed. Refs are hard.

[gregsdennis]

I think this is the cause

https://github.com/gregsdennis/json-everything/pull/75/files#diff-5a7712dfe232287659fbbe6cd3b9fcad14a4a20083d9cfa60f506c5f04f42ba8L67-R68

I remember I needed to make that change in the $dynamicRef and $recursiveRef keywords, but I may have been overzealous in changing $ref as well.

Also, your test case may be a good candidate for the JSON Schema Test Suite. I run against that suite every build, and it passed, so this case isn't there already.

[amosonn]

Interesting. I'll take a look into adding it to that test suite!

Regarding the place that you mentioned, I remember already snagging once on the fact that CurrentUri sometimes actually contains the "parent directory" of the uri referring to the current schema. I think it was possible to get diagnostics where some uris were incorrect because of this. I'd wanted to write a minimal test-case but never got around to it.

My point is, it could be that the change you made there actually uncovered an underlaying problem. The last time I looked at it I tried to find a simple solution that will make sure that CurrentUri always contains the uri of the current schema, but didn't manage it. As you said, $ref-s are hard :)

[gregsdennis]

Yep, that's what did it. The idea with the change was that I wanted to first check if the current URI was resolveable, and take the schema root if not. It looks like you've found a case where that check throws an exception for some reason. This is important if the URI completely changes while navigating the schema.

For example:

// schema
{
  "$id": "https://mydomain.com/outer",
  "properties": {
    "foo": {
      "$id": "https://mydomain.com/foo",
      "properties": {
        "inner1": {
          "$anchor": "bar",
          "type": "string"
        },
        "inner2": {
          "$ref": "#bar"
        }
      }
    },
    "bar": {
      "$anchor": "bar",
      "type": "integer"
    }
  }
}

// passes
{
  "foo": {
    "inner2": "value"
  }
}

// fails
{
  "foo": {
    "inner2": 42
  }
}

The first instance passes because the URI changes when navigating to the $ref from outer to foo, which means that we need to resolve foo#bar. The subschema at /properties/bar has a URI of outer#bar.

I think I just need to figure out why the exception is thrown rather than changing the $ref resolution.

[gregsdennis]

The exception is thrown from your test code when trying to resolve the URI. If you use the code that you commented out (the TryGetValue() line), then it works just fine. 😑

[gregsdennis]

The reason for the call, however... I'm not sure. My example still works without the change, as does the test suite.

I'll revert this change and republish.

[amosonn]

Sorry, I should have written this more clearly. Of course the exception is from my code, and one could argue that a good Fetch should return null and not throw exceptions when e.g. a file is missing. OTOH, if I know what schemas would need to be fetched, and that the files are all there, then I shouldn't expect it to be called with a "strange" uri.

I left the exception-throwing version to highlight this; i.e., the bug is IMO that this uri was ever fetched. If you use the version which silencesthis exception in the test, it will not catch this bug.

Put otherwise: in the test which you added, I would have used the following Fetch:

uri =>
{
    map.TryGetValue(uri, out var ret).AssertTrue();
    return ret;
}

since the only uris passed to this fetch should be in that dictionary. This would then indeed fail the test gracefully and not with an error (and also be more readable).