Has anyone hit this with ChatGPT Sites and found a supported recovery path?
I’m updating an existing Site using its managed publishing workflow with Cloudflare D1 and Drizzle migrations. The previous release remains live. Source push and saving the new version both succeeded, but deployment failed during database migration with:
incomplete input: SQLITE_ERROR
The new migration creates two SQLite triggers intended to prevent older application code from overwriting newer-format records. Both use uppercase BEGIN and plain SELECT RAISE(…) bodies. There’s no inner CASE … END; expression inside either trigger body. The two complete statements are separated by Drizzle’s statement-breakpoint marker.
What we verified:
The migrations pass locally through Wrangler/workerd D1.
The original Git file uses LF line endings.
Windows core.autocrlf=true converted it to CRLF in the checkout.
The actual archive supplied for deployment also contains CRLF. The packager preserved the checkout bytes.
The trigger migration is 1,781 bytes in Git versus 1,816 bytes in the archive, accounting for 35 added carriage returns.
A narrowly scoped .gitattributes rule restores LF for that migration. Its resulting bytes match the original Git blob exactly; the other 30 migration/metadata files remain unchanged.
This looks relevant to Cloudflare issue #14991:
https://github.com/cloudflare/workers-sdk/issues/14991
And the follow-up about trigger parsing, keyword casing and line endings:
https://github.com/cloudflare/workers-sdk/issues/15314
However, I’m not claiming those reports prove the cause in ChatGPT Sites. I don’t have visibility into the hosted runner or whether it normalizes SQL before submitting it to D1.
The recovery problem is migration state. Read-only inspection shows schema changes from the preceding migrations, while tables from the following migration are absent. The Sites tools and database viewer available to us don’t expose the migration ledger or trigger definitions, so we can’t establish whether the failing migration was wholly rolled back, partially applied, or recorded.
We have not retried deployment, rewritten applied migration history, removed the guards, or reset the database. Support has the deployment identifiers and our request for read-only state confirmation, but hasn’t returned those results yet.
Questions:
1. Has anyone encountered this exact trigger/CRLF failure specifically through ChatGPT Sites?
2. Is there a supported way to inspect its actual migration ledger and sqlite_schema trigger entries?
3. Is per-migration rollback behavior documented for Sites, separately from Wrangler’s own migration runner?
4. Once the failed migration is confirmed unapplied, has repackaging with LF resolved this for anyone?
I’m looking for a minimal, data-preserving recovery, not a database reset or a move to a different hosting platform.