Structured Log — Duplicate Keys in One JSON Object (jsonl)
Records whose objects declare the same key twice, including one where the duplicate changes the severity from debug to error. RFC 8259 permits duplicate names and leaves the outcome undefined, so last-wins and first-wins parsers disagree about what these records say.
{"ts":"2026-03-17T09:14:32.850Z","level":"info","msg":"first value","msg":"second value","seq":1}
{"ts":"2026-03-17T09:14:33.100Z","level":"debug","level":"error","msg":"level declared twice","seq":2}
{"ts":"2026-03-17T09:14:33.350Z","user":{"id":"a","id":"b"},"msg":"duplicate key nested","seq":3}
{"ts":"2026-03-17T09:14:33.600Z","level":"info","msg":"no duplicates here","seq":4}
Specifications
- Lines
- 4
- Records With Duplicates
- 3
- Nested Duplicate
- true
- Severity Changed By Duplicate
- true
- Rfc8259
- duplicate names are permitted but behaviour is undefined
Testing contract
Expected to recover- Scenario
- Parse the four records and record the resulting level and msg values.
- Expected result
- The parser's duplicate-key policy is explicit and documented — record 2 resolves to either debug or error consistently — rather than varying between the JSON library and the log pipeline.
What is a .jsonl file?
JSONL (JSON Lines) is a text format where each line is a complete, independent JSON value, allowing records to be streamed and appended without parsing the whole file. It is not itself a JSON array and each line must stand alone. It is common in logging, machine learning datasets, and data pipelines.
How to use this file
Use an example JSONL to test line-by-line streaming parsers, append-and-resume ingestion, and batch pipelines that process one record per line.
How to use this file for testing
“Structured Log — Duplicate Keys in One JSON Object (jsonl)” is a deterministic Novus Examples fixture for Observability, Log parsing, JSON parsing. Structured and plain-text telemetry with known timestamps, levels, request identifiers, and error states for testing log ingestion, correlation, dashboards, and alert pipelines.
Documented properties for this file: JSONL · 383 bytes. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Telemetry fixtures use fixed trace IDs, span IDs, and timestamps so ingestion is reproducible run to run. Point your collector, parser, or query layer at the file and assert the documented span tree, metric families, or severity mix; service and host names are invented.
Code examples
import json
with open("app-duplicate-json-keys.jsonl") as f:
rows = [json.loads(line) for line in f]
print(len(rows), rows[0])Related files
- jsonOTLP Logs — Export Document with Severity and Trace Correlation (json)An OTLP logs export across two resources: five records spanning DEBUG to FATAL with both severityNumber and severityText, separate event and observed timestamps, trace and span correlation, and one record whose body is a full multi-line Python traceback.
- jsonlAlert State History — Pending, Firing and Resolved Transitions (jsonl)Sixteen state transitions across four alerts, each moving inactive to pending to firing to resolved with the previous state recorded. The pending stage is where a for: duration is being served and no notification is sent, which is what makes alert-noise analysis possible.
- logDocker Container Log — json-file driver (log)A Docker json-file container log — one JSON object per line with the log text, stream (stdout/stderr), and an RFC 3339 timestamp, exactly as Docker's default logging driver writes it. A fixture for container-log shippers and parsers.
- log.NET Exception with an Inner Exception Chain (log)A .NET exception whose inner exception is introduced by the ---> marker and closed by End of inner exception stack trace, wrapped in pipe-delimited log lines. Error groupers that key on the outermost message alone merge two genuinely different faults here.
- logCRI Container Log — Partial Lines and Two Streams (log)The CRI log format Kubernetes nodes actually write: an RFC 3339 nanosecond timestamp, a stream name, and an F or P tag marking whether the line is full or a partial continuation. One long message is split across several P lines that must be rejoined before parsing.
- logGo Panic with Full Goroutine Dump (log)A Go panic followed by the runtime's full goroutine dump — four goroutines with their wait states, two-line frames and a created by attribution, separated by blank lines. Blank-line separation defeats multi-line rules that treat an empty line as the end of an event.
Generated by generation/observability.py. Free for any use, no attribution required — license.