Duplicate object keys handling change with Jackson 2.13 FAIL_ON_READING_DUP_TREE_KEY

The goal is to define a consistent duplicate-key policy for JSON objects consumed across services that use different parsers and library versions. RFC 8259 does not prescribe how duplicate object keys must be handled, leaving the behavior implementation-specific.

The compatibility boundary centers on Jackson 2.13, which added the mapper feature FAIL_ON_READING_DUP_TREE_KEY to reject duplicates, whereas Jackson 2.12 and earlier silently used the last value. Gson, Python’s built-in json module, and Node.js JSON.parse also adopt last-wins semantics with no built-in option to detect duplicates.

With heterogeneous runtimes in use, the decision is whether to enforce strict rejection, allow silent last-wins, or normalize inputs before parsing.

What configuration transition is appropriate when moving from Jackson 2.12 to 2.13+ without breaking existing payloads? How can duplicate keys be detected in environments that provide no built-in detection? Should duplicate keys be treated as a schema violation consistently across all parsers?