feat: URL resolving support for validate & metaschema #605

robbat2 · 2026-01-10T15:35:07Z

Closes: #234
Co-authored-by: Codex codex@openai.com
Generated-with: OpenAI Codex CLI (partial)
Signed-off-by: Robin H. Johnson rjohnson@coreweave.com

robbat2 · 2026-01-10T16:14:04Z

Interesting heisenbug failure - the URL is fine, but it had a 404 when the test ran?

435/451 Test #435: JSONSchema.ci.fail_bundle_http_non_schema_verbose .............................***Failed    0.60 sec
2,3c2,5
< error: HTTP 404
<   at https://schemas.sourcemeta.com/self/v1/api/schemas/stats/jsonschema/2020-12/schema
---
> error: The JSON document is not a valid JSON Schema
>   at identifier https://schemas.sourcemeta.com/self/v1/api/schemas/stats/jsonschema/2020-12/schema
>   at file path /tmp/tmp.psSZLWYWpc/schema.json
>   at location "/allOf/0/$ref"

        Start 439: JSONSchema.ci.fail_validate_http_non_schema_verbose
436/451 Test #431: JSONSchema.ci.pass_bundle_http ................................................   Passed    0.74 sec

jviotti · 2026-01-13T12:06:09Z

Interesting feature! Thanks for sending it. I'll book some time today to properly review it 🙏🏻

jviotti

I love the idea. I think the way Codex/you are implementing it is fighting the current machinery for iterating on schema arguments. I think we need for make for_each_json transparently work with both URLs or file paths. The src/input.h file abstracts a way a lot of the logic, including line number gathering, reading, etc so that the actual commands never have to worry about it.

for_each_json will loop and pass specific positional arguments to handle_json_entry. It feels to me that such handle_json_entry needs to take either a path or a URI (maybe just a string?) and then internally check: if it is a path and it exists and it is a file, do X, if it is a directory, do Y, if it is an HTTP/S URL, do Z.

I think if we do all of that there, we very elegantly gain URL support in every applicable command.

jviotti · 2026-01-14T13:42:47Z

On the transient CI failure, yeah, we've been getting that quite a bit recently. I'm on it right now!

jviotti · 2026-01-14T13:59:30Z

If you merge main back in, the transient CI issue should be gone!

Closes: sourcemeta#234 Co-authored-by: Codex <codex@openai.com> Generated-with: OpenAI Codex CLI (partial) Signed-off-by: Robin H. Johnson <rjohnson@coreweave.com>

robbat2 · 2026-01-14T22:06:57Z

couple more CI bumps from the code but ready again; nothing transient this time

jviotti

I left some comments. I also wonder if there is a way to split up this PR so it's easy to merge the core logic first and avoid git conflicts, but not sure what that would be 🤔

jviotti · 2026-01-21T12:54:42Z

src/input.h

+      -> const std::filesystem::path & {
+    if (!this->path.has_value()) {
+      std::ostringstream error;
+      error << "The `" << command << "` command does not support HTTP inputs";


Note we never dynamically construct strings for exceptions. Instead, use one of the existing error classes that would be handled in src/error.h or create a new exception class there

jviotti · 2026-01-21T12:55:39Z

src/input.h

+  }
+
+  [[nodiscard]] auto base_uri() const -> std::string {
+    if (sourcemeta::jsonschema::is_http_url(this->first)) {


Suggested change

if (sourcemeta::jsonschema::is_http_url(this->first)) {

if (is_http_url(this->first)) {

You are already in the sourcemeta::jsonschema:: namespace, so you can omit it in every case.

jviotti · 2026-01-21T12:56:16Z

src/input.h

+    return this->path.value();
+  }
+
+  [[nodiscard]] auto base_uri() const -> std::string {


This method is called base_uri but it doesn't return a base URI, but the whole file URI given the path?

jviotti · 2026-01-21T12:56:54Z

src/input.h


 struct InputJSON {
-  std::filesystem::path first;
+  std::string first;


If the thing here is that the first might be either a path or a URI, maybe a std::variant expresses this better

jviotti · 2026-01-21T12:58:32Z

src/input.h

+    const auto path_without_query_or_fragment =
+        sourcemeta::jsonschema::uri_path_without_query_or_fragment(
+            entry_identifier);
+    if (path_without_query_or_fragment.ends_with(".jsonl")) {


Beyond just the extension, I think we need to look at the content type mime header?

jviotti · 2026-01-21T13:12:17Z

test/ci/pass_validate_schema_http.sh

+{ "name": "foo", "kind": "example" }
+EOF
+
+"$1" validate "http://127.0.0.1:$PORT/schema.json" "$TMP/instance.json" --http \


I'm now wondering if a command invocation to an HTTP URL should assume --http. I think it makes sense?

jviotti · 2026-01-21T13:13:12Z

test/ci/pass_validate_schema_http_suffix_json_over_plain_content_type.sh

+"$1" validate "http://127.0.0.1:$PORT/schema.json?ignored=1" "$TMP/instance.json" \
+  --http 2>"$TMP/stderr.txt"
+
+cat << EOF > "$TMP/expected.txt"


Can we run all of these that present no output with --verbose and actually capture BOTH stdout and stderr? i.e. if for whatever reason this command printed non-sense to stdout, we would never know

jviotti · 2026-01-21T13:14:07Z

test/lint/pass_lint_file_uri.sh

+SCHEMA_PATH="$(cd "$TMP" && pwd)/schema.json"
+SCHEMA_URI="file://$SCHEMA_PATH"
+
+"$1" lint "$SCHEMA_URI" --json >"$TMP/output.json" 2>&1


Maybe add a _json suffix to the test file as this is only covering the JSON part?

jviotti · 2026-01-21T13:14:58Z

test/metaschema/fail_schema_url_without_http.sh

I get this test, but I'm wondering now if it is a bit confusing. I think if any input is an HTTP URL, we should assume --http, as that's clearly the user's intent?

jviotti · 2026-01-21T13:15:25Z

test/metaschema/pass_file_uri.sh

+EOF
+
+diff "$TMP/output.txt" "$TMP/expected.txt"
+


Looks like various test files have this empty line here?

robbat2 force-pushed the rjohnson/http-fetch-validate branch from 050993e to eca24c0 Compare January 10, 2026 16:04

jviotti requested changes Jan 14, 2026

View reviewed changes

robbat2 force-pushed the rjohnson/http-fetch-validate branch 2 times, most recently from 6bf416d to 3d93e71 Compare January 14, 2026 20:35

robbat2 requested a review from jviotti January 14, 2026 20:40

feat: URL resolving support for validate & metaschema

7ced116

Closes: sourcemeta#234 Co-authored-by: Codex <codex@openai.com> Generated-with: OpenAI Codex CLI (partial) Signed-off-by: Robin H. Johnson <rjohnson@coreweave.com>

robbat2 force-pushed the rjohnson/http-fetch-validate branch from 3d93e71 to 7ced116 Compare January 14, 2026 20:43

jviotti requested changes Jan 21, 2026

View reviewed changes

	if (sourcemeta::jsonschema::is_http_url(this->first)) {
	if (is_http_url(this->first)) {

feat: URL resolving support for validate & metaschema #605

Are you sure you want to change the base?

feat: URL resolving support for validate & metaschema #605

Uh oh!

Conversation

robbat2 commented Jan 10, 2026

Uh oh!

robbat2 commented Jan 10, 2026

Uh oh!

jviotti commented Jan 13, 2026

Uh oh!

jviotti left a comment

Choose a reason for hiding this comment

Uh oh!

jviotti commented Jan 14, 2026

Uh oh!

jviotti commented Jan 14, 2026

Uh oh!

robbat2 commented Jan 14, 2026

Uh oh!

jviotti left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants