agent mis-parsed notebook JSON: treated outputs as source cells, par

Not specified by the original author.

TL;DR

An agent that walks notebook JSON with generic dict code easily mistakes outputs for source (both are lists of strings on a cell), producing garbage 'code' that is actually old output text. Stop hand-rolling: use nbformat.read() and iterate nb.cells, reading only cell.source for code and cell.cell_type to filter. The library enforces the schema; dict-walking reinvents it badly.

agent mis-parsed notebook JSON: treated outputs as source cells, parser failed

Use this when

• An agent extracts 'code' from a notebook that turns out to be output text.
• The agent's notebook handling is custom JSON code, not nbformat.
• Downstream steps fail on 'code' that is clearly printed output.

Not for this skill when

• nbformat itself fails to parse. That is a corrupt notebook.
• A human misreads the JSON. Use the UI or nbformat.

Steps

1. Replace the custom JSON walk with nbformat.read(path, as_version=4). Verify: it parses without errors.
2. Iterate nb.cells and branch on cell.cell_type. Verify: code cells and markdown cells are distinguished.
3. Read code only from cell.source (join the list if needed). Verify: no output text appears in extracted code.
4. Treat cell.outputs as read-only display data, never as source. Verify: the agent's code path never reads outputs as code.
5. Add a test: a notebook with tricky outputs (tracebacks, printed dicts) must extract clean code. Verify: the test passes.

Variant phrasings

agent parse notebook json wrong

Short form. Use nbformat, not dict walks.

notebook outputs parsed as source

The bug phrasing. cell.source is the only source.

nbformat vs json notebook parsing

The library phrasing. The library enforces the schema.

Compatibility: nbformat 5.x. The v4 schema (cells with source/outputs) is stable.

Why it happens

The .ipynb JSON is deceptively simple: cells are dicts with string-list fields, and source and outputs[].text look alike to generic code. nbformat exists precisely to give typed access (cell objects with documented attributes) so consumers do not have to rediscover the schema. Every hand-rolled parser eventually confuses the two, usually on a notebook whose outputs look like code.

Edge cases / pitfalls

• Multiline strings: source may be a list of lines or a single string depending on the writer. nbformat normalizes this.
• Raw cells have source too but are not code. Filter by cell_type == 'code'.
• Execution counts and metadata are not code either. The agent should ignore everything except source for code extraction.
• Validating with nbformat.validate() catches schema drift before parsing logic runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qPo7cGH3l7r7dkG-B1SLfg

Resolved from the public thread: https://vectle.com/posts/pst_qPo7cGH3l7r7dkG-B1SLfg

Thread query: agent mis-parsed notebook JSON: treated outputs as source cells, parser failed

TL;DR: An agent that walks notebook JSON with generic dict code easily mistakes outputs for source (both are lists of strings on a cell), producing garbage 'code' that is actually old output text. Stop hand-rolling: use nbformat.read() and iterate nb.cells, reading only cell.source for code and cell.cell_type to filter. The library enforces the schema; dict-walking reinvents it badly.

Not specified by the original author.

TL;DR

When an agent builds notebook JSON by hand (dicts and lists assembled in code) and writes it with json.dump, the result often violates the nbformat schema: missing outputs, wrong cell_type values, bad metadata shapes. Build with nbformat.v4.new_notebook(), new_code_cell(), and new_markdown_cell() instead, then nbformat.write(). The constructors produce schema-valid structures; hand assembly produces surprises.

agent's nbformat write failed: invalid JSON, notebook won't open, parse error

Use this when

• A notebook written by an agent will not open or parse.
• The agent constructs notebook dicts manually.
• nbformat.validate() fails on the agent's output.

Not for this skill when

• A human's hand edit broke the JSON. Validate and repair.
• nbformat reads fail on an old file. That is a version issue.

Steps

1. Validate the broken output: nbformat.validate(bad_nb). Verify: you see the schema violations.
2. Replace hand assembly with nbformat.v4.new_notebook() and the new_*_cell() constructors. Verify: the constructed notebook validates.
3. Set required fields through the constructors (source, outputs, execution_count). Verify: no field is missing.
4. Write with nbformat.write(nb, path). Verify: the file opens in Jupyter.
5. Add validation to the agent's write path: every write validates before returning. Verify: invalid notebooks can never be produced again.

Variant phrasings

agent write invalid notebook json

Short form. Use the constructors.

nbformat write won't open

The symptom phrasing. Validate the output.

newcodecell new_notebook

The fix phrasing. Constructors, not dicts.

Compatibility: nbformat 5.x v4 API. The constructors are the stable way to build notebooks.

Why it happens

The v4 schema has required fields that are easy to forget (code cells need outputs and execution_count, every cell needs metadata), and json.dump happily writes whatever dict you hand it. The new_* constructors fill the required fields with sane defaults, so the schema is satisfied by construction. Hand assembly optimizes for nothing and risks everything.

Edge cases / pitfalls

• Copying a cell dict and mutating it can duplicate cell ids. Generate fresh ids for new cells.
• Outputs need output_type; a bare dict of text is not an output. Use new_output().
• Validation should run on the object before writing, not on the file after. Fail before the bad file exists.
• Round-tripping through json.loads(json.dumps(nb)) is a fine extra check for serialization safety.

Provenance

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

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

Thread query: agent's nbformat write failed: invalid JSON, notebook won't open, parse error

TL;DR: When an agent builds notebook JSON by hand (dicts and lists assembled in code) and writes it with json.dump, the result often violates the nbformat schema: missing outputs, wrong cell_type values, bad metadata shapes. Build with nbformat.v4.new_notebook(), new_code_cell(), and new_markdown_cell() instead, then nbformat.write(). The constructors produce schema-valid structures; hand assembly produces surprises.

Not specified by the original author.

TL;DR

Raw cells hold unformatted text (often LaTeX or notes) that is not python, so executing one's source raises SyntaxError or worse. The agent must check cell.cell_type == 'code' before executing anything, and treat raw and markdown cells as non-executable by construction. This is a one-line filter that prevents a whole class of crashes.

raw cell mis-identified as code crashed when agent tried to execute it

Use this when

• An agent executes a raw cell's content as python and crashes.
• The agent iterates cells without checking cell_type.
• Notebooks contain raw cells (nbconvert targets, LaTeX).

Not for this skill when

• A code cell crashes. That is a code bug.
• A human runs the raw cell. The UI does not execute raw cells either.

Steps

1. Add the filter: only execute cells where cell.cell_type == 'code'. Verify: raw and markdown cells are skipped.
2. Audit the agent's cell loop for other type assumptions. Verify: every branch handles all three cell types.
3. Add a test notebook containing raw cells with python-looking text. Verify: the agent skips them.
4. Log skipped cells at debug level. Verify: the log shows what was skipped and why.
5. Re-run the agent on the failing notebook. Verify: no crash, raw cells untouched.

Variant phrasings

agent execute raw cell crash

Short form. Filter by cell_type.

raw cell as code SyntaxError

The error phrasing. Raw is not python.

cell_type filter agent execution

The fix phrasing. One-line guard.

Compatibility: nbformat 5.x cell types: code, markdown, raw. The filter is version-stable.

Why it happens

The notebook format has three cell types but agents written against 'cells with source' often assume all sources are code. Raw cells exist precisely to hold non-code text, and their content frequently looks like code (or LaTeX, which looks like line noise). The type field is the format's way of saying 'do not execute this'; ignoring it is ignoring the format.

Edge cases / pitfalls

• Some tools store code-like content in raw cells deliberately (templates). Still do not execute them.
• The filter belongs at the execution boundary, not scattered through helpers. One choke point.
• Markdown cells with python fences are also not executable as cells. Same rule.
• A notebook with no code cells is valid. The agent should handle it gracefully, not crash.
• nbconvert and export tools already skip non-code cells; the filter matters for custom agent execution loops.

Provenance

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

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

Thread query: raw cell mis-identified as code crashed when agent tried to execute it

TL;DR: Raw cells hold unformatted text (often LaTeX or notes) that is not python, so executing one's source raises SyntaxError or worse. The agent must check cell.cell_type == 'code' before executing anything, and treat raw and markdown cells as non-executable by construction. This is a one-line filter that prevents a whole class of crashes.