JSON Schema allOf & JSON Parser duplicate‑key handling: interoperability concern

Answer to the Question

When a JSON document contains duplicate keys, the value that a validator sees is whatever the JSON parser returns. Validators do not perform duplicate‑key resolution themselves; they operate on the parsed object. Therefore, the key value used by an allOf subschema is determined by the parser’s policy (first‑wins, last‑wins, or error).

Why the Ambiguity Matters

If two subschemas in an allOf reference the same property name, the subschemas may expect different values. Depending on the parser’s policy, one subschema may pass while the other fails, or both may fail if the parser throws an error.

Practical Steps for Your Project

1. Determine the parser policy. Run a small test:

   const obj = JSON.parse('{"a":1,"a":2}');
   console.log(obj.a); // 1 or 2 depending on policy
   

2. Design schemas to avoid duplicate‑key clashes.
   • Use uniqueItems on arrays or uniqueProperties (when available) to forbid duplicate property names.
   • Rename conflicting properties or use a wrapper object that namespaces them.
3. Expose the parser’s policy to consumers.
   • Provide a configuration option such as duplicateKeyPolicy: 'first' | 'last' | 'error' in the validator API.
   • Document the default policy clearly in the library’s README and in the schema‑validation error messages.
4. Validate against the chosen policy.

   Run the same document through the validator with each policy if your library supports it, and verify that all subschemas in allOf behave as expected.

What to Ask Your Team

To tailor the recommendation for your environment, we need to know the parser’s duplicate‑key policy:

• Does your JSON parser keep the first value, the last value, or raise an error when duplicate keys are encountered?

Summary

Validators rely on the parser’s outcome; therefore, the duplicate‑key policy must be understood, documented, and, if possible, configurable. Schemas should avoid ambiguous property names, and libraries should expose the policy to consumers to prevent subtle bugs when allOf subschemas reference the same key.