[wrangler] Fix D1 SQL splitter under-splitting migrations with a CASE...END followed by a comma - #15234
Open
mittalpk wants to merge 4 commits into
Open
[wrangler] Fix D1 SQL splitter under-splitting migrations with a CASE...END followed by a comma#15234mittalpk wants to merge 4 commits into
mittalpk wants to merge 4 commits into
Conversation
…...END followed by a comma isCompoundStatementEnd() only recognized END as closing a compound statement when the next character was ';' or whitespace. A CASE used as a value expression (SET x = CASE ... END, y = 1) is legitimately followed directly by a comma, so that END went undetected, leaving the splitter's nesting tracker permanently one level too deep for the rest of the file -- every remaining statement got silently merged into one oversized blob. Broadened the check to any non-identifier character, matching what already worked for ';' and whitespace. Fixes cloudflare#15162.
🦋 Changeset detectedLatest commit: d33fed6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
workers-devprod
requested review from
a team and
jamesopstad
and removed request for
a team
August 17, 2026 09:09
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
@cloudflare/autoconfig
@cloudflare/build-output-utils
@cloudflare/codemods
@cloudflare/config
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-functions
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-plugin
@cloudflare/workers-auth
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>
…ed CASE isCompoundStatementEnd() was broadened to accept any non-identifier character after END (to fix cloudflare#15162's comma case), but isCompoundStatementStart() still required whitespace immediately before CASE/BEGIN. A parenthesised CASE used as a value expression, e.g. (CASE ... END), is preceded by '(' with no space -- its start was never detected, but its END now was. That let an inner CASE's END) prematurely close an unrelated, already-open compound statement (e.g. an enclosing trigger's BEGIN ... END), corrupting the split. Broadened isCompoundStatementStart() the same way, so detection is symmetric on both sides. Thanks to Devin Review for catching this.
Contributor
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #15162
splitSqlIntoStatements()tracks nestedBEGIN/CASEblocks so it doesn't split a semicolon that's inside a trigger body or aCASEexpression. It detected the end of a block by checking whetherENDwas followed by;or whitespace — but aCASEused as a value expression (e.g.SET x = CASE ... END, y = 1, which is exactly what the reporter's real migration file does) is legitimately followed directly by a comma. When that happened, the block'sENDwent undetected, leaving the splitter's internal nesting tracker permanently one level too deep for the rest of the file — every remaining statement got silently merged into one giant blob instead of being split correctly.Reproduced with the reporter's linked repro repo: the 5th migration file (667 lines, ~193 real statements) was being collapsed into 2. Passing that single oversized "statement" through D1's local
batch()execution is what produced the reporteddatabase table is locked: SQLITE_LOCKEDerror — confirmed by rebuilding wrangler both with and without the fix and running the exact repro both ways, live.Fix: broaden the single trailing-character check from
[;\s]to any non-identifier character, soEND,andEND)are recognized the same wayEND;andENDalready were.