Adding a remote overwrites earlier remote schema diagnostics

[MicroMilo]

Summary

compileSchema promises to validate all supplied schemas and its main compilation path accumulates diagnostics, but addRemoteSchema replaces the owner's schemaErrors/schemaAnnotations on every call and omits schemaId assignment. A remotes list therefore retains only the last remote's diagnostics.

Impact: With two invalid entries in options.remotes, schemaErrors has length 1, loses the first remote's #/anyOf/0 error, and leaves the surviving #/type error's schemaId undefined.

Code path

Checked against current main at commit 1cc2a3045f615ef67104f02449c6fd58afebeb6a.

• README.md:118-124
• src/compileSchema.ts:176-195
• src/SchemaNode.ts:580-594

Steps to reproduce

Validation level: current HEAD supplemental dynamic witness reproduced.

node -e "const fs=require('fs'),vm=require('vm'); vm.runInThisContext(fs.readFileSync('dist/jlib.js','utf8')); const remotes=[{'\$id':'https://a.example/schema',anyOf:[999]},{'\$id':'https://b.example/schema',type:'invalid-type'}]; const node=jlib.compileSchema({}, {remotes}); console.log(JSON.stringify({count:node.schemaErrors.length,schemaIds:node.schemaErrors.map(e=>e.data.schemaId),pointers:node.schemaErrors.map(e=>e.data.pointer)}))"

Observed output:

{"count":1,"schemaIds":[null],"pointers":["#/type"]}

Neighboring control:

node -e "const fs=require('fs'),vm=require('vm'); vm.runInThisContext(fs.readFileSync('dist/jlib.js','utf8')); const remotes=[{'\$id':'https://a.example/schema',anyOf:[999]}]; const node=jlib.compileSchema({}, {remotes}); console.log(JSON.stringify({count:node.schemaErrors.length,schemaIds:node.schemaErrors.map(e=>e.data.schemaId),pointers:node.schemaErrors.map(e=>e.data.pointer)}))"

Control output:

{"count":1,"schemaIds":["https://a.example/schema"],"pointers":["#/anyOf/0"]}

Expected behavior

The documented/source-grounded contract should hold without the drift described above.

Actual behavior

Registering later remotes erases earlier diagnostics, loses provenance, and can bypass throwOnInvalidSchema.

Existing coverage

I checked the current issue and PR lists for overlapping titles/root-cause keywords before filing this. I did not find an item covering this same root cause.

Suggested fix

Accumulate addRemoteSchema diagnostics and assign each remote's schemaId instead of replacing the existing arrays.

Suggested tests

• Add a regression test for the reproduction above.
• Add a neighboring control assertion so the intended non-bug path remains covered.

---

Submitted with Codex.

[sagold]

Hi Xingjing,

nice catch and thank you for reaching out. This issue will be addressed - I will keep you posted.

Cheers,
Sascha

[Adityakumar37]

Hey @sagold , I can take this one if you haven't started yet.

Looks like addRemoteSchema in SchemaNode.ts is overwriting node.schemaErrors / schemaAnnotations on each call instead of appending to them, and it never sets schemaId on the errors (unlike compileSchema, which does). That's why only the last remote's diagnostics survive.

I'll fix it to accumulate + tag each error with its remote url, and add a regression test (two invalid remotes) plus a control test (single remote) to lock in the behavior.

[sagold]

Hi Aditya,

thank you for the offer! I planned to take some time to check if the schema validation requires a refactoring to support this as a primary feature having better control of retrieving storing and evaluating errors. So right now, I do not have any guidance here, but you can still take a shot at it.

In case you have questions, I probably will take some time to respond. Looking forward to your proposal.

Cheers,
Sascha