agent stripped output cells but left dangling execution_count values

Not specified by the original author.

TL;DR

Stripping cell outputs but leaving execution_count set produces a notebook that claims it ran (counts 1..40) with no outputs to show for it, which confuses diffing, review, and re-execution. Strip both together: set cell.outputs = [] and cell.execution_count = None for every code cell. Better yet, use nbconvert --clear-output, which does exactly this. The notebook should look unexecuted, because it is.

agent's output strip failed: left dangling execution_count values, wrong state

Use this when

• A 'cleaned' notebook still shows execution counts with no outputs.
• Diffs of cleaned notebooks show phantom changes in counts.
• The agent strips outputs with custom code.

Not for this skill when

• Outputs remain after stripping. That is a strip bug, not a count bug.
• A human strips via the UI. The UI handles counts correctly.

Steps

1. Inspect: check that stripped cells have execution_count: null. Verify: counts are cleared, not just outputs.
2. Fix the strip code: for each code cell, set outputs to [] and execution_count to None. Verify: the object reflects both.
3. Prefer the standard tool: jupyter nbconvert --clear-output --inplace. Verify: it clears both.
4. Validate the result: nbformat.validate(nb). Verify: it passes.
5. Add a test asserting stripped notebooks have null counts. Verify: the regression cannot return.

Variant phrasings

strip outputs execution_count left

Short form. Clear counts with outputs.

nbconvert clear-output counts

The tool phrasing. It handles both.

dangling execution count notebook

The state phrasing. Null them on strip.

Compatibility: nbformat 5.x, nbconvert 6/7. execution_count null is the schema-correct cleared state.

Why it happens

Execution counts are metadata about a past run, and outputs are its artifacts; they are a pair. Custom strip code usually handles the visible half (outputs) and forgets the numeric half (counts), leaving a notebook in a state that never occurs naturally: executed but outputless. Tools that diff or re-execute notebooks read the counts as signal, so the phantom counts cause real confusion downstream.

Edge cases / pitfalls

• Some diff tools treat null vs missing execution_count differently. Null is correct; missing can fail validation.
• Stripping outputs does not strip widget state. Clear that too for a truly clean notebook.
• The agent should strip before committing, not after. Clean notebooks in version control, always.
• Re-execution after stripping renumbers from 1. That is correct and expected.

Provenance

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

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

Thread query: agent's output strip failed: left dangling execution_count values, wrong state

TL;DR: Stripping cell outputs but leaving execution_count set produces a notebook that claims it ran (counts 1..40) with no outputs to show for it, which confuses diffing, review, and re-execution. Strip both together: set cell.outputs = [] and cell.execution_count = None for every code cell. Better yet, use nbconvert --clear-output, which does exactly this. The notebook should look unexecuted, because it is.

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

An agent that re-runs cells out of order can mutate a shared dataframe (drop columns, filter rows) and then crash on the next read that expects the original. Give the agent one rule: dataframes are rebuilt from source, never mutated in place across cells, and execution is strictly top to bottom. Make destructive operations idempotent (rebuild rather than modify) so a re-run produces the same frame instead of a corrupted one.

agent re-ran cells out of order and broke the shared dataframe, crash on read

Use this when

• An agent's run crashes reading a dataframe an earlier cell modified.
• Re-running cells changes the dataframe (rows disappear on second run).
• Multiple cells mutate the same frame in place.

Not for this skill when

• A human's interactive out-of-order run. Restart-and-run-all fixes it manually.
• The read fails on a missing file. That is a path problem.

Steps

1. Find the mutating cell: diff the dataframe before and after each cell. Verify: you know which cell corrupts it.
2. Rewrite the cell to rebuild the frame from source instead of mutating. Verify: running it twice gives the same frame.
3. Enforce top-to-bottom execution in the agent with no selective re-runs. Verify: execution counts are sequential.
4. Add an assertion after the build cell (expected columns, row count sanity). Verify: corruption fails fast with a clear message.
5. Re-run the agent end to end. Verify: reads succeed and the frame is intact.

Variant phrasings

agent out of order cells dataframe

Short form. Rebuild, do not mutate.

notebook cell re-run corrupts dataframe

The symptom phrasing. Idempotent builds fix it.

shared dataframe broken agent execution

General phrasing. Single-writer, strict order.

Compatibility: pandas/polars notebooks under any agent runner. The idempotence rule is library-agnostic.

Why it happens

In-place mutation (drop, query with inplace, filtered reassignment) makes a cell non-idempotent: the first run transforms the data, the second run transforms the transformed data. Interactive users rarely notice because they restart kernels often. Agents re-run cells freely, so non-idempotent cells corrupt shared state deterministically, and the crash lands on an innocent later read.

Edge cases / pitfalls

• Rebuilding from source on every run is slower but correct. Correct first, then optimize with caching.
• Copies vs views: chained assignment can mutate the original through a view. Use explicit .copy() where needed.
• The agent should treat 'cell already ran' as irrelevant; with idempotent cells, re-running is always safe.
• Global dataframes shared across notebooks are a worse version of this. Scope frames to one notebook.

Provenance

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

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

Thread query: agent re-ran cells out of order and broke the shared dataframe, crash on read

TL;DR: An agent that re-runs cells out of order can mutate a shared dataframe (drop columns, filter rows) and then crash on the next read that expects the original. Give the agent one rule: dataframes are rebuilt from source, never mutated in place across cells, and execution is strictly top to bottom. Make destructive operations idempotent (rebuild rather than modify) so a re-run produces the same frame instead of a corrupted one.