agent's cell splitter cut a multiline string across cells

Not specified by the original author.

TL;DR

Splitting a code cell in the middle of a triple-quoted string produces two cells that are each a syntax error, because the string literal is now unterminated in both. The agent must split on parsed statement boundaries (using Python's own tokenizer or AST), never on line counts or blank lines. If a statement spans the split point, keep it whole in one cell. Syntax validity of every resulting cell is the acceptance test.

agent's cell splitter broke a multiline string across cells, syntax error

Use this when

• Split cells raise SyntaxError on strings that were fine before.
• The agent splits cells by line count or heuristics.
• Triple-quoted strings, decorators, or brackets span the split.

Not for this skill when

• The original cell had a syntax error. Fix the source first.
• A human splits in the UI. The UI splits at the cursor, which is also risky.

Steps

1. Parse the cell with ast.parse() before splitting. Verify: the original parses cleanly.
2. Split only between top-level statements (AST statement boundaries). Verify: no statement is divided.
3. After splitting, compile() each new cell's source. Verify: every cell compiles.
4. If a statement is too large to split (one giant string), keep it whole and note why. Verify: the unsplittable cell is flagged, not broken.
5. Add the compile check to the splitter permanently. Verify: invalid splits are impossible.

Variant phrasings

split cell syntax error multiline string

Short form. Split at statement boundaries.

agent cell splitter broken

The agent phrasing. AST boundaries, then compile-check.

notebook split unterminated string

The symptom phrasing. Keep strings whole.

Compatibility: Python 3, nbformat 5.x. ast and compile are stdlib.

Why it happens

Code is not lines; it is a token stream where strings, brackets, and decorators create structure that line-based splitting cannot see. A triple-quoted string looks like several innocent lines to a line counter, but splitting inside it breaks the token stream in both halves. Parsing first (even just tokenizing) reveals the true boundaries, and the compile check proves the split is safe.

Edge cases / pitfalls

• Blank lines are not statement boundaries. Decorated functions and multi-line calls span them.
• Cell magics (%%) are not Python; handle them before AST parsing or exclude those cells.
• Splitting changes execution semantics if statements shared state implicitly. Splits should be behavior-preserving.
• The splitter should refuse to split rather than produce invalid cells. Refusal is a feature.

Provenance

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

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

Thread query: agent's cell splitter broke a multiline string across cells, syntax error

TL;DR: Splitting a code cell in the middle of a triple-quoted string produces two cells that are each a syntax error, because the string literal is now unterminated in both. The agent must split on parsed statement boundaries (using Python's own tokenizer or AST), never on line counts or blank lines. If a statement spans the split point, keep it whole in one cell. Syntax validity of every resulting cell is the acceptance test.

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.

Not specified by the original author.

TL;DR

wrangler d1 execute prints results as a pretty ASCII table, and agents split columns on whitespace. Wide values containing spaces shift every column after them, corrupting the parse. Use the JSON output format for machine parsing and leave the pretty table for humans.

The query

agent failed to parse wrangler d1 execute table output: column splitter broke on wide rows

Use this when

• D1 results parse fine for narrow rows, garbage for wide ones.
• The agent's extracted values are shifted or merged.
• The same query works when a human reads the table.

Not for

• D1 query errors (fix the SQL).
• Empty result sets (nothing to parse).
• Agents already using JSON output (different bug).

Steps

Step 1: Confirm the parse corruption

Run the query and compare the agent's parsed values against the raw table.

Expected result: columns after any space-containing value are shifted. The whitespace split is the culprit.

Step 2: Switch the agent to JSON output

npx wrangler d1 execute [db] --remote --command "SELECT ..." --json

Expected result: the output is structured JSON with named fields. No column splitting is needed or possible.

Step 3: Parse the JSON properly

Read the result array and access fields by name. Handle the envelope format wrangler wraps around the rows.

Expected result: values are correct regardless of width, spaces, or unicode. The parse is robust by construction.

Step 4: Ban pretty-table parsing in the runbook

Expected result: every agent D1 read uses --json. The pretty table is for humans at terminals only.

Step 5: Verify with the widest real row

Run the previously-failing query and check the agent's extracted values.

Expected result: correct values for the wide rows that broke the old parser.

Why it happens

Pretty tables are a human interface: alignment is visual, and spaces inside values are indistinguishable from column separators to a naive splitter. Agents reach for the default output (the table) and write the simplest parser (split on whitespace). It works until the first wide row, which is usually production data.

Edge cases

• JSON output can be large for big result sets. Page with LIMIT/OFFSET rather than parsing megabytes.
• The --json envelope differs between wrangler versions. Parse defensively: find the rows array, do not assume a fixed path.
• Nulls, numbers, and blobs have JSON representations that differ from the table's. Handle types, not just strings.
• If the agent must show humans a table, render it FROM the parsed JSON rather than parsing the rendered table.

Provenance

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

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

Thread query: agent failed to parse wrangler d1 execute table output: column splitter broke on wide rows

TL;DR: wrangler d1 execute prints results as a pretty ASCII table, and agents split columns on whitespace. Wide values containing spaces shift every column after them, corrupting the parse. Use the JSON output format for machine parsing and leave the pretty table for humans.