JSONL / invalid-row handoff

Repair invalid JSONL rows without losing line identity

Keep the one-JSON-value-per-line contract and separate valid, malformed and empty lines by original line number. Put any repair candidate beside the source and review it before handoff.

Keep original line numbers

The fixture numbers physical lines from 1. The extra text on line 2 and the empty line 3 stay distinct from the valid row on line 4.

LineStateDiagnosisDecision
1Validvalid JSONKeep original
2InvalidTrailing contentRepair review
3EmptyNot a JSON valueDo not export
4Validvalid JSONKeep original

Review a candidate beside the source

Line 2 can show a candidate with the trailing text removed, but this guide does not decide that the candidate is correct. Hand off the original invalid line, diagnosis, candidate and reviewer together.

line 2  original: {"id":2,"name":"B"} trailing
line 2  candidate: {"id":2,"name":"B"}
decision: repair-review

This guide does not guarantee the receiver's schema, required fields or acceptance.

Review before handoff

  1. Keep the source and number physical lines from 1.
  2. Classify each line as valid, invalid or empty and record the reason.
  3. Keep a candidate beside an invalid source line and mark it for review.
  4. Do not silently discard invalid or empty lines; document every exclusion.
  5. After approval, run the receiver's JSONL validation again.

This guide is static browser-local material. Input, files and validation results are not sent to or stored by an external service.

Do not treat invalid rows as success

If line numbers are compacted, the result can no longer be matched to the source log or a reprocessing result. Even when exporting only valid rows, record every excluded line and its reason first.