JSON parse error in session-jTJ7kLrt.jsonl export

The assistant was investigating a bug in the oc-export project where running it on a JSONL session file produced a JSON parse error despite the file appearing to be valid JSON. After verifying the file's raw bytes (7b 0a, which is { followed by a newline) with hexdump, the assistant determined the content was well-formed UTF-8, ruling out data corruption. The assistant then moved to inspect the project's source files (render.ts, parseInputFile, extractors, types) and the package.json to understand how the tool reads the input and where it calls JSON.parse, suspecting either a BOM issue or an incorrect parser invocation in the render pipeline. The planned next step was to reproduce the error by running oc-export against the file and locating the exact line where parsing fails, in order to apply a fix.

The assistant was investigating a bug in the oc-export tool where an exported .jsonl file produces a misleading JSON parse error at position 1. After reading the file in data/session-jTJ7kLrt.jsonl, it discovered the file was truncated at 65404 bytes, ending mid-property at line 1062 with an unterminated string. Building the project and running it on the file reproduced the user's error.

The assistant traced the misleading "Expected property name or '}' in JSON at position 1 (line 1 column 2)" message to parseInputFile: when JSON.parse of the whole file fails (here due to truncation), the code falls back to line-by-line JSONL parsing. Because the file is actually a pretty-printed single JSON object whose first line is just {, the line-by-line parser fails with that confusing error and the real "Unterminated string at position 65404" error is swallowed. The assistant built and ran the dist output to confirm this behavior.

It also explored whether the truncation itself originated in spawnToFile or in the external opencode export command, checking spawnToFile's pipe and out.end() handling and looking for size limits or timeouts in config.ts, but found no obvious internal cause for the 65404-byte truncation. The assistant concluded that the concrete code-level bug is the JSONL fallback in parseInputFile masking the original parse error, while the truncation itself appears to come from the export step, not from oc-export's file writing.

The assistant investigated a bug where an exported session JSONL file was truncated and the renderer produced a confusing error. Tracing through the code, the root cause was identified as a flawed heuristic in the parseInputFile fallback: when JSON.parse failed on the full file, the code attempted to parse the file line by line as JSONL, which is invalid for a single pretty‑printed JSON object. That fallback generated the unhelpful "Expected property name" error. The assistant also examined the spawnToFile helper and confirmed that pipe‑based stdout capture works correctly for larger outputs, so the truncation was unlikely to be caused by stream handling. The local database did not contain the reported session, so the export could not be reproduced, but the malformed JSON was clearly an incomplete export (ending mid‑property rather than at a closing brace).

The conclusion was to fix parseInputFile by detecting whether the file looks like a single JSON object (opening { and closing } on the outer lines) and, if so, abandoning the line‑by‑line fallback. Instead, the original parse error should be rethrown with a clearer message indicating that the exported file is incomplete. Additional small improvements to be made included: registering an error listener on the writable stream in spawnToFile to surface write failures, and avoiding a no‑op out.end() call on an already‑ended stream. These changes will give a much more accurate error to the user when the exported file is truncated and prevent the misleading JSONL parse error from masking the real problem.

I traced the bug to two issues in the render/export pipeline:

The spawnToFile helper in src/util.ts used proc.stdout.pipe(createWriteStream(outputPath)). Node pipes buffer up to the highWaterMark (default 64KB) before pausing the source. Because opencode export writes the entire JSON to stdout and then calls process.exit(0) without draining, the OS pipe buffer only contains the first 65536 bytes. That exactly matches your session-jTJ7kLrt.jsonl, which is hard‑limited to that size. The compiler then threw a misleading "Expected property name" message because parseInputFile in src/render.ts noticed the first non‑empty line "{" looked JSON‑valid but the JSONL fallback tried JSON.parse(lastLine), which failed on a bare "p".

I fixed spawnToFile to skip the pipe entirely: open the output file with fs.openSync(outputPath, "w") and pass the numeric fd as the child's stdout (stdio: ["ignore", fd, "pipe"]). The child inherits the fd and writes straight to the file; the OS flushes the descriptor on exit, so even an immediate process.exit(0) produces a complete file. I also tightened parseInputFile to recognise pretty‑printed single‑JSON documents (first non‑empty line "{" or "[" that is not itself a parseable value) and surface the original parser error instead of going through JSONL.

After rebuilding with npm run build, data/manual-export.json renders cleanly to 4 turns, data/session-jTJ7kLrt.jsonl now prints Failed to parse ... as a single JSON document: Unterminated string in JSON at position 65404 (line 1062 column 11), and a synthetic child that mimics process.exit(0) after writing 194KB is captured fully with the new helper versus only 64KB with the old pipe. The truncated artifact itself cannot be repaired, but any future export through oc-export will be complete.