wrangler d1 migrations apply fails on trigger migration while d1 execute --file succeeds

[authoralicianorman-cloud]

wrangler d1 migrations apply fails where d1 execute --file succeeds

Status: root cause isolated, not yet filed with Cloudflare.
Impact: staging cannot be brought up to date. Any future migration
containing triggers will not deploy to production either.
Investigated: 2026-08-11, in a disposable D1 database created and deleted in
the same session. Staging and production were never touched.

Summary

npx wrangler d1 migrations apply <db> --remote fails with:

A request to the Cloudflare API (/accounts/…/d1/database/…/query) failed.
  incomplete input: SQLITE_ERROR [code: 7500]

The identical migration file applies successfully through
wrangler d1 execute <db> --remote --file <same file> — 98 queries, no error.

The SQL is therefore valid and the remote API accepts it. The fault is in the
migrations apply code path, which appends its own ledger INSERT to the
migration text and re-splits the combined statement list differently than
--file does.

Minimal reproduction

Failing file: migrations/0043_partner_trust.sql (23,753 bytes, 21 triggers).

# Fails — incomplete input: SQLITE_ERROR [code: 7500]
npx wrangler d1 migrations apply <db> --remote

# Succeeds — "Executed 98 queries in 77.67ms"
npx wrangler d1 execute <db> --remote --file migrations/0043_partner_trust.sql

Both run against the same database, at the same migration position (42 prior
migrations applied), with the same wrangler version.

What was ruled out, and how

Every hypothesis below was tested and disproven. Recorded so nobody re-walks
them.

Hypothesis	Test	Result
wrangler version regression	Retried on 4.121.0	Same failure
…specifically a regression since production migrated	Retried on 4.113.0, the version pinned in the lockfile at the commit that authored these migrations	Same failure
Invalid SQL	scripts/check-migrations-replay.mjs replays all 106 into empty SQLite	106/106 clean
Invalid SQL (D1 semantics)	Fresh local D1, migrations apply --local	All applied
Triggers are unsupported remotely	Single CREATE TRIGGER via --file to a remote DB	Succeeded
Production never really had them	SELECT COUNT(*) FROM sqlite_master WHERE type='trigger' on production	93 triggers, incl. partner_payout_* from 0058
Batch size / payload limit	60 trivial non-trigger migrations via migrations apply	All applied; wrangler applies one file per request
BEGIN … ; END; on a single line breaks the splitter	Two triggers, identical semantics, one multi-line and one single-line	Both succeeded
The file itself is bad	d1 execute --file on 0043	Succeeded, 98 queries

The last two rows together are the finding: same file, same database, same
version — fails through one command, succeeds through the other.

Why staging reports a different first-failure than the replay

Staging has 0001–0057 applied and reports 49 pending from 0058. The
disposable replay started empty and stopped after 0042, i.e. on 0043. Both
are the same defect surfacing at whichever trigger-bearing migration each
database reaches first.

Proposed workaround — NOT YET IMPLEMENTED

Design only. Requires review before it is written or run.

For each pending migration, in ledger order:

1. wrangler d1 execute <db> --remote --file <migration> — the path proven to
   work.
2. Insert the ledger row that migrations apply would have written, so the
   migration is not re-applied later.
3. Re-read the ledger and assert it advanced by exactly one, and that the
   expected name is present, before moving to the next file.

Requirements this must meet:

• Ordered. Never skip or reorder; a data migration may depend on a schema
  migration before it.
• Resumable. Re-running after an interruption must continue, not restart.
• Ledger-verified before and after every step, not just at the end.
• Aborts on the first failure rather than continuing.
• Must not run against production without a separate, explicit decision.

The ledger table name and row shape must be read from a database wrangler
itself has written, not assumed.

Filing

Not yet filed. When filed, against cloudflare/workers-sdk, include: the
summary, the two commands, the ruled-out table, wrangler versions 4.113.0 /
4.120.0 / 4.121.0 all reproducing, and the observation that --file succeeds
on identical input.

[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: #15178

Summary

wrangler d1 migrations apply --remote fails with incomplete input: SQLITE_ERROR [code: 7500] on a migration file containing SQLite triggers, while wrangler d1 execute --remote --file on the identical file succeeds — pointing at a divergence in how the migrations apply code path assembles and submits SQL versus the --file path.

Classification

• Type: Bug
• Component: packages/wrangler (D1 command code lives in wrangler)
• Severity: High
• Has Reproduction: Partial (clear CLI commands and error, plus a thorough ruled-out table, but the triggering migration file itself is referenced rather than attached; remote-only repro needs live D1 access)
• Quality: Complete

Findings

• Created: 2026-08-13
• Author: authoralicianorman-cloud
• Version: wrangler 4.113.0, 4.120.0, and 4.121.0 (all reproduce)
• Labels: none
• Comments: 2 (both automated advisory triage reports from the workers-devprod bot; no maintainer or reporter follow-up)

Analysis

• Component is clearly D1/wrangler. The failure is specific to the wrangler d1 migrations apply command path; the d1 execute --remote --file path handles the same SQL correctly. D1 command code lives in packages/wrangler.
• High-quality report with root cause narrowed. The reporter isolated the fault to the migrations apply path appending its own ledger INSERT (into the d1_migrations table) to the migration text and re-splitting the combined statement list differently than --file does. The failing file is 23,753 bytes with 21 triggers, consistent with a splitter mishandling compound BEGIN...END trigger bodies once concatenated with an appended statement.
• Likely deeper root cause — different API endpoints. A follow-up automated comment notes that migrations apply sends combined SQL to the /query endpoint, whereas execute --file uploads raw SQL to the /import endpoint. This endpoint/handling divergence — not merely local statement splitting — is the most probable cause of the remote-only incomplete input error, since /query re-parses concatenated statements while /import ingests the file wholesale.
• Not a version regression. Reproduced across 4.113.0, 4.120.0, and 4.121.0; the reporter explicitly tested and disproved the regression hypothesis (along with several others: local D1 semantics, remote trigger support, payload/batch size, single-line BEGIN...END, and "the file is bad").
• Not caught by any closeable category. Not spam, not resolved, not a prior-release fix, not a duplicate referenced in-issue, not a runtime/workerd or third-party-framework issue, not stale (created 2026-08-13), not transient, and not user error — the SQL is valid and accepted by the remote API via --file.
• Gap for maintainers. The actual migration file (or a minimal trigger-only repro) is not attached, and remote reproduction is blocked without a live D1 database and API credentials. A maintainer will need the file or a synthesized equivalent to reproduce and fix.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-documented, reproducible bug in the d1 migrations apply code path with a plausible root cause (the migrations apply path submits concatenated SQL + ledger INSERT to /query, which mishandles compound trigger statements, while execute --file uploads to /import and succeeds). It is not covered by any close category and blocks applying trigger-containing migrations to remote D1 databases.

Action: Triage to the D1/wrangler team. Investigate the difference between the migrations apply (/query) and execute --file (/import) paths, and how migrations apply assembles the ledger INSERT alongside migration SQL and splits the combined statement list. Reproduce with a migration file containing SQLite triggers plus the appended ledger INSERT. Ask the reporter for the migration file (or a minimal trigger-only repro) to accelerate.

Suggested Labels: none (omitting — cannot confirm from the available data which package:/product: labels exist in the repo; do not invent labels)

Suggested Comment

Thanks for the detailed investigation — isolating this to the migrations apply path (where the ledger INSERT is appended and the combined statements are re-split, and which submits to the /query endpoint rather than /import like --file does) is really helpful.

To let us reproduce and fix this quickly, could you share a minimal migration file that triggers the failure? Ideally a small standalone .sql with one or two triggers (CREATE TRIGGER ... BEGIN ... END;) that fails under d1 migrations apply --remote but succeeds under d1 execute --remote --file. A GitHub repo we can clone and run against a throwaway D1 database would be ideal.

In the meantime, wrangler d1 execute --remote --file <migration> is a viable workaround for applying the affected migration.

Structured summary (JSON)

{
  "issueNumber": 15178,
  "title": "wrangler d1 migrations apply fails on trigger migration while d1 execute --file succeeds",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15178",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-documented, reproducible bug in the d1 migrations apply code path: it appends a ledger INSERT and submits the combined SQL to the /query endpoint, which mishandles compound trigger (BEGIN...END) statements, whereas d1 execute --file uploads to /import and succeeds on the identical SQL. The fault is in wrangler's migrations apply path, not the SQL.",
  "suggestedAction": "Triage to the D1/wrangler team; investigate the /query vs /import endpoint difference and how migrations apply concatenates the ledger INSERT with migration SQL and splits statements. Request a minimal trigger-only migration file (or repro repo) from the reporter.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ⚠️ Blocked. Requires Cloudflare remote D1 DB and API credentials. Confirmed migrations apply sends combined SQL to /query while execute --file uploads raw SQL to /import. Exact remote-only incomplete input: SQLITE_ERROR cannot be reproduced without live D1 access.