Error fixes / Cloudflare
Cloudflare
D1: no such table
The Worker queried a table that this D1 database does not have.
The error
D1_ERROR: no such table: subscribers: SQLITE_ERROR
What it means
D1 is SQLite. no such table means the migration that creates the table has not been applied to the database the Worker is using. Local wrangler state, a preview database, and the remote database are different. Creating the table in the dashboard SQL console for one of them does not update the others. A typo in the table name does the same thing.
Fix
- Read the table name in the error and compare it with the CREATE TABLE statement, including spelling.
- Apply migrations to the database you are actually calling. wrangler d1 migrations apply NAME --local updates the local one. The remote flag updates the deployed database.
- If the Worker is deployed, a local migration is not enough. Apply remotely, then hit the route again.
- Do not point production at a scratch database you created for a tutorial and then forgot.
- Keep schema changes in migration files so the next environment can replay them.
Prompt
Fix prompt
D1 returns D1_ERROR: no such table for a table this app expects. Compare the query with the migrations. If the CREATE TABLE is missing, add a migration. Do not create the table by hand only in a dashboard session. Tell me the exact wrangler d1 migrations apply command for local and for remote, and do not run the remote one yourself. Do not drop an existing table to 'start again' unless I ask.
Questions
The table shows in the dashboard. Why does the Worker disagree?
You may be looking at a different D1 database than the binding, or at remote data while the dev server uses local state. Check the binding's database name and whether the command used --local or --remote.
Can I paste CREATE TABLE into the console and skip migrations?
You can, once. The next environment will miss it. Put the statement in a migration file and apply that.
Will this error show as Error 1101?
If the Worker does not catch it, yes. The D1 message is in the logs. Catch it only to return a clear 500, and still fix the schema.