eval dataset JSONL parse error invalid line fails run

Not specified by the original author.

TL;DR

Fix this in Doccano by acting on the exact message first: open the file at line 12, fix the malformed JSON on that line (unescaped quotes inside the text field are the usual cause), validate that every line parses on its own, then reimport. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

JSONL file contains invalid record at line 12

Use this when

• The operation in Doccano fails with this exact message: JSONL file contains invalid record at line 12.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Doccano, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: open the file at line 12, fix the malformed JSON on that line (unescaped quotes inside the text field are the usual cause), validate that every line parses on its own, then reimport. Verify: every line parses independently and the import count matches the line count.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in Doccano on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in Doccano so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

JSONL needs one complete JSON object per line; one broken line aborts the import at that line.

Variant phrasings

JSONL file contains invalid record at line 12

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: Doccano import failed error "JSONL file contains invalid record at line 12"

The how-to phrasing for the same failure in Doccano. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Doccano troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: Doccano at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstn9Zot1xAwzFlV6itLznqg

Resolved from the public thread: https://vectle.com/posts/pstn9Zot1xAwzFlV6itLznqg

Thread query: Doccano import failed error "JSONL file contains invalid record at line 12"

TL;DR: Fix this in Doccano by acting on the exact message first: open the file at line 12, fix the malformed JSON on that line (unescaped quotes inside the text field are the usual cause), validate that every line parses on its own, then reimport. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR: A failed fine-tune job almost always means the training file was malformed. Validate the JSONL locally, read the job events for the exact error, and start small before relaunching the full run. Each blind retry burns money, so never relaunch without knowing the cause. Confirm the cause Validate the training file locally before it touches the API: 1.

The error

. A typo in a role name fails the whole file.
3. **Upload purpose.** The file must be uploaded with purpose

The symptom

The fine-tuning job errors out or sits in failed state. Each blind retry burns money, so never relaunch without knowing the cause.

Confirm the cause

Validate the training file locally before it touches the API:

1. JSONL shape. One complete JSON object per line. No pretty-printed multi-line objects, no trailing commas.
2. Message format. Each line needs a messages array, every message with role and content. A typo in a role name fails the whole file.
3. Upload purpose. The file must be uploaded with purpose fine-tune. A file uploaded for another purpose is not accepted as training data.
4. Size sanity. Check token counts per example. Pathological examples turn a validation problem into a billing problem.

Then read the job's events, not just its status. The events carry the specific validation error: which line, which field. Fix that exact thing.

The fix

1. Write a local validator: every line parses as JSON, has a messages array, every message has role and content, no empty strings where forbidden.
2. Fix all errors, re-upload with purpose fine-tune, launch a new job.
3. Start with a few hundred examples to prove the pipeline before training on the full dataset.
4. Estimate cost from token counts before the full run.

Verify the fix

The validator passes clean on the exact file uploaded. The new job reaches running state with steady progress in its events, not a validation error. Keep the validator in the pipeline so the next dataset is checked automatically.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: OpenAI fine-tune job failed.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current OpenAI behavior.

OpenAI's fine-tuning guide requires the dataset uploaded formatted in JSONL with purpose fine-tune, and job events surface the specific validation errors. Local validation of line shape and message format before launching avoids paying for repeated failed jobs (https://platform.openai.com/docs/guides/fine-tuning).

Not specified by the original author.

TL;DR

Separate the streams before parsing: Azure ML run history JSONL mixes system log lines with metric records, so filter lines by their record type or source field, or read the metrics through the run API instead of the raw history file. The file is a merged log, not a metrics export. Lines that are not metric records are not corruption; they were never meant for the metrics parser.

parser failed on Azure ML run history jsonl with interleaved system logs error

Use this when

• The check or run fails with this symptom: a parser fails on Azure ML run history JSONL with interleaved system logs.
• You are working on an agent workflow extracting metrics from Azure ML run history files and the failure repeats on the same data or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A history file where system lines are also malformed JSON, which needs line tolerant parsing as well as filtering.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Sample lines from the file and classify them by their fields. Verify: metric records and system records have distinguishable shapes
2. Filter to metric records using the type or source field present in the file. Verify: the filtered stream contains only metric lines
3. Parse the filtered stream as JSONL. Verify: every retained line decodes
4. Cross-check the parsed metric count against the run summary in the portal or API. Verify: counts agree
5. Where the API can serve the same metrics, switch the workflow to it and keep the file path as fallback. Verify: future reads skip the mixed file

Variant phrasings

parser failed azure ml run history jsonl interleaved logs

The shorter phrasing focused on the named failure.

azure ml run history parse error agent

The symptom phrasing a searcher tries next.

azure ml jsonl metric filtering fix

The variant naming the failing stage or tool directly.

Compatibility: Azure ML run history and log files, JSONL parsing in agent workflows

Why it happens

Run history files collect whatever the run and the platform write: metrics, system events, and library logs share one append stream. A parser written against a clean metrics only sample breaks on the first system line in a real run, and longer runs guarantee such lines exist.

Edge cases / pitfalls

• Line tolerant parsing that skips undecodable lines must still count and report the skips, or system lines hide real metric corruption.
• Record type fields change across platform versions; classify by several fields, not one magic string.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nqs8xznym9MFLPDLWG3vWg

Resolved from the public thread: https://vectle.com/posts/pst_nqs8xznym9MFLPDLWG3vWg

Thread query: parser failed on Azure ML run history jsonl with interleaved system logs error

TL;DR: Separate the streams before parsing: Azure ML run history JSONL mixes system log lines with metric records, so filter lines by their record type or source field, or read the metrics through the run API instead of the raw history file. The file is a merged log, not a metrics export. Lines that are not metric records are not corruption; they were never meant for the metrics parser.