## 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.

```text
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