[wrangler] D1 SQL splitter does not treat bracket-quoted identifiers as quoted

[MatheusMartinho]

Which Cloudflare product(s) does this pertain to?

Wrangler core, D1

What versions are you using?

main (reproduced at 898dc6e)

Describe the Bug

splitSqlIntoStatements() in packages/wrangler/src/d1/splitter.ts scans for quotes so that SQL syntax inside them is not interpreted. It handles ', " and backticks, but not SQLite's bracket-quoted identifiers ([name]).

As a result a trigger body that references such an identifier is split apart. Given:

CREATE TRIGGER t AFTER INSERT ON items
BEGIN
 UPDATE x SET [end] = 1;
 UPDATE y SET z = 2;
END;
SELECT 1;

splitSqlQuery() returns four fragments instead of two:

CREATE TRIGGER t AFTER INSERT ON items\nBEGIN\n UPDATE x SET [end] = 1
UPDATE y SET z = 2
END
SELECT 1

Each fragment is then sent to D1 separately, so wrangler d1 execute --file and wrangler d1 migrations apply fail or apply a migration partially.

Notably normalizeSqlLineEndings(), in the same file, does treat [ … ] as a quote pair, so the two scanners disagree about the same syntax.

Please provide a link to a minimal reproduction

The snippet above reproduces directly through splitSqlQuery(); no account or network access is needed.

Additional context

Found while working on #15226, which fixes a different splitter issue (compound statement markers that are not padded with whitespace). This one is pre-existing and independent — it reproduces identically before and after that change — and needs a fix in the scanner rather than in the marker regexes, so it is filed separately. Happy to send a PR.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15228

Summary

D1's SQL statement splitter (splitSqlIntoStatements()) does not treat SQLite bracket-quoted identifiers ([name]) as quotes, so trigger bodies containing them get split into multiple fragments, breaking wrangler d1 execute --file and wrangler d1 migrations apply.

Classification

• Type: Bug
• Component: packages/wrangler (D1 SQL splitter, src/d1/splitter.ts)
• Severity: Medium
• Has Reproduction: Yes (self-contained SQL snippet; runs directly through splitSqlQuery(), no account/network needed)
• Quality: Complete

Findings

• Created: not specified in context data
• Author: MatheusMartinho
• Version: main (reproduced at commit 898dc6e)
• Labels: none captured in context data
• Comments: 1 (an automated triage report from workers-devprod)

Analysis

• Component is clearly identified. The reporter points to the exact file and functions: splitSqlIntoStatements() / splitSqlQuery() in packages/wrangler/src/d1/splitter.ts. D1 code lives in the wrangler package.
• Root cause is diagnosed in the report. The quote scanner handles ', ", and backtick pairs, but not SQLite's [ ... ] bracket-quoted identifiers. A trigger body like UPDATE x SET [end] = 1; is therefore split on the semicolon inside the identifier context, yielding four fragments instead of two.
• Strong internal evidence of the bug. The reporter notes normalizeSqlLineEndings() in the same file does treat [ … ] as a quote pair, so the two scanners in one file disagree — a clear inconsistency that supports the diagnosis.
• Reproducibility is excellent. The provided SQL exercises the code path directly without any external dependencies, making this easy to verify with a unit test.
• Independence established. The reporter distinguishes this from the related [wrangler] Recognise compound statement markers without surrounding whitespace #15226 (a different splitter fix), noting it reproduces identically before and after that change and needs a scanner-level fix rather than a marker-regex fix.
• Note: the exact source path could not be verified in this checkout (the packages/wrangler tree is not present here), but this does not affect the triage — the report is self-contained and internally consistent.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-scoped, clearly reproducible bug with a diagnosed root cause and a self-contained repro. The reporter has offered to send a PR. It is a genuine tooling correctness issue in the D1 SQL splitter, not a duplicate, runtime, or user-error case.

Action: Accept the issue and welcome the offered PR. The fix should extend the quote scanner in splitSqlIntoStatements() to treat [ … ] as a quote pair (matching the existing behavior in normalizeSqlLineEndings()), and add a unit test using the trigger snippet in the report. Confirm this is separate from #15226.

Suggested Labels: none (label names not verifiable from the provided context; omitted to avoid guessing)

Suggested Comment

Thanks for the detailed report and root-cause analysis — this is clear and easy to reproduce. It does look like the quote scanner in splitSqlIntoStatements() should treat SQLite bracket-quoted identifiers ([ ... ]) as a quote pair, consistent with what normalizeSqlLineEndings() already does in the same file. A PR would be very welcome; if you can include a unit test using the trigger snippet above, that would be ideal.

Structured summary (JSON)

{
  "issueNumber": 15228,
  "title": "D1 SQL splitter does not handle bracket-quoted identifiers ([name]), splitting trigger bodies incorrectly",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15228",
  "recommendation": "KEEP OPEN",
  "difficulty": "easy",
  "reasoning": "Well-scoped, reproducible bug with a diagnosed root cause in the D1 SQL splitter's quote scanner, which omits SQLite bracket-quoted identifiers. The reporter offered a PR.",
  "suggestedAction": "Accept the issue and welcome the offered PR; extend the quote scanner in splitSqlIntoStatements() to treat [ ... ] as a quote pair and add a unit test using the trigger snippet.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ❌ Could not reproduce. The exact trigger example from the issue returned 2 fragments, not the reported 4; however, semicolons inside bracket-quoted identifiers (e.g. [a;b]) are incorrectly treated as statement terminators, confirming the root cause is present in the scanner.

[jamesopstad]

Please provide a minimal reproduction that is user-facing rather than using internal functions.

[MatheusMartinho]

Here's a user-facing reproduction — and a correction to the issue as filed, because building the repro surfaced an error in my report.

Repro (wrangler 4.123.0, --local, no account or network needed):

wrangler.jsonc

{
	"name": "d1-splitter-repro",
	"compatibility_date": "2026-08-01",
	"d1_databases": [
		{
			"binding": "DB",
			"database_name": "repro-db",
			"database_id": "00000000-0000-0000-0000-000000000000"
		}
	]
}

schema.sql

CREATE TABLE metrics ([value;unit] TEXT);

$ npx wrangler d1 execute repro-db --local --file=schema.sql
🌀 Executing on local database repro-db (00000000-0000-0000-0000-000000000000) from .wrangler/state/v3/d1:

✘ [ERROR] unrecognized token: "[value" at offset 22: SQLITE_ERROR

The same run, as it appears in the terminal:

The file is valid SQLite — sqlite3 :memory: "CREATE TABLE metrics ([value;unit] TEXT); SELECT [value;unit] FROM metrics;" runs fine — but the splitter cuts the statement at the ; inside the bracket-quoted identifier and sends CREATE TABLE metrics ([value to D1. Comment markers inside bracket identifiers misbehave the same way: in SELECT [a--b] FROM t; everything from -- to the end of the line is dropped as a comment.

Correction: the trigger/[end] example in the issue body does not reproduce on main — the triage bot's reproduction note was right. I had measured those four fragments on my #15226 branch and wrongly concluded the behaviour was identical on main; in fact the whitespace-delimited END marker on main never fires inside [end], and that trigger file executes correctly on 4.123.0 (verified with the same setup). So on released wrangler this issue is narrower than I described: it needs a ; or comment marker inside a bracket-quoted identifier. The [end]-inside-a-trigger-body variant was a regression that #15226 would have introduced.

Because of that entanglement I fixed both in #15226 rather than in a separate PR: as of de80155 the scanner consumes [ … ] like the other quote styles, with regression tests covering the [value;unit] and trigger cases — that branch shouldn't land without it. Happy to split the scanner change into its own PR if you'd prefer this issue addressed independently.