Stale metaschema resolution after $schema and $id URI changes

[davieshq]

Summary

After updating $schema and $id URIs across a large schema library (~80 files), the jsonschema test command reports a stale metaschema identifier that no longer exists in any schema file.

Steps to reproduce

1. Start with a schema library where all files use a custom dialect as their $schema:

   { "$schema": "https://example.com/v2/dialect.json", "$id": "https://example.com/v2/asset.json" }

2. Update all files to use the standard 2020-12 dialect and new $id URIs:

   { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/v3/asset.json" }

3. Rename the directory from v2/ to v3/ and update all --resolve paths accordingly.

4. Verify with grep that no file contains the old URI (example.com/v2/dialect.json) — confirmed clean.

5. Run jsonschema test tests/v3/asset/ --resolve v3/asset.json --resolve v3/dialect.json [... all other resolves]

Expected behaviour

All tests pass, since the target schema (asset.json) now uses $schema: https://json-schema.org/draft/2020-12/schema.

Actual behaviour

error: Could not resolve the metaschema of the schema
  at identifier https://example.com/v2/dialect.json
  at file path tests/v3/asset/asset.test.json

This is likely because you forgot to import such schema using `--resolve/-r`

The old dialect URI (v2/dialect.json) is referenced in the error, but does not exist in any file on disk. Other test suites (e.g. kinship.test.json) targeting simpler schemas pass without issue.

Environment

• jsonschema CLI: installed via pnpm (latest as of April 2026)
• Node: v22.22.1
• OS: Ubuntu 24.04 (WSL2)

Context

This was encountered during the INHERIT open estate data standard's v2→v3 migration. The affected schema (asset.json) uses allOf + if/then composition referencing 5 category sub-schemas — it's the most complex schema in the library, which may be relevant to reproduction.

The issue may be related to internal caching of metaschema resolution during a single jsonschema test run, where earlier resolved schemas (which pass) establish a resolution context that persists for later schemas.

Workaround

Not yet found — clearing node_modules/.cache did not help. The schema files themselves are verified correct.

[davieshq]

Update: reinstalling the package (pnpm remove + pnpm add) does not resolve the issue, confirming this is not a file/disk cache problem.

Additional findings:

• Running without --resolve v3/dialect.json produces the same error
• Recursively tracing all $ref chains from the failing schema confirms zero files contain openinherit.org/v2 in any $schema or $ref value
• 27 of 45 test suites pass (simpler schemas). 15 failing suites all report the same stale identifier
• 3 additional suites that were failing due to stale test data have been fixed and now pass

The pattern suggests the CLI may be constructing metaschema resolution from the file path or $id history rather than from the declared $schema value in the loaded file.

[jviotti]

Hey @davieshq ,

Do you have a ZIP with the reproducible case that I can test? I'm not able to reproduce as per the instructions, but I might be missing something. Are you sure you don't have a leftover defaultDialect in the jsonschema.json from before the migration?

For context, the tool does not perform any caching whatsoever. It purely runs from the input, so I wonder if there is something else in the context kicking in.

What do you see if you re-run with --verbose or even with --debug?