cli icon indicating copy to clipboard operation
cli copied to clipboard

Supabase will not start after latest update (to 1.203.0).

Open Stokestack opened this issue 1 year ago • 5 comments

Describe the bug After being informed by the CLI that an update was available, I did a brew update/upgrade. After that

supabase start

in my dev tree failed with lots of

00:01:51.050 [error] Postgrex.Protocol (#PID<0.4721.0>) failed to connect: ** (Postgrex.Error) FATAL 3D000 (invalid_catalog_name) database "_supabase" does not exist

Expected behavior Supabase starting

Screenshots If applicable, add screenshots to help explain your problem.

System information Rerun the failing command with --create-ticket flag.

  • Ticket ID: c52d2c1706f44c1a936ef52af8f67269
  • Version of OS: Mac OS 15.0.1
  • Version of CLI: 1.203.0
  • Version of Docker: 27.3.1, build ce1223035a
  • Versions of services: "Access token not provided."

Starting with supabase start --ignore-health-check

appears to launch OK.

Probably a dupe of https://github.com/supabase/cli/issues/2737 but I don't think that title reflects the severity of the problem.

Stokestack avatar Oct 09 '24 05:10 Stokestack

It seems indeed duplicate.

Did you tried the suggestions on the issues ? Does the problem persist for you ?

Could you try supabase stop --no-backup followed by start? We switched to a new initialisation routine that's not compatible with local db state.

@ThingEngineer I started with analytics.enabled = false then did supabase db reset and that worked for me to create the missing database and schemas. Obviously this removes all your local data.

Another possibility to keep your local data would be to manually connect to the database container and manually run the migration:

CREATE DATABASE _supabase WITH OWNER postgres;
-- connect to _supabase database
\c _supabase
CREATE SCHEMA IF NOT EXISTS _analytics;
ALTER SCHEMA _analytics OWNER TO postgres;

CREATE SCHEMA IF NOT EXISTS _supavisor;
ALTER SCHEMA _supavisor OWNER TO postgres;

avallete avatar Oct 09 '24 07:10 avallete

Fortunately I had not tried the DB reset yet, so I can try the tests you requested.

Restarting after supabase stop --no-backup failed, because I only had seed-data INSERTs in seed.sql, not table creation. So my custom DB tables were missing.

So I added table-drop & creation at the top of seed.sql. Now I'm getting

failed to send batch: ERROR: column "messageID" of relation "User_x_Message" does not exist (SQLSTATE 42703)

Which is wrong, because at the top of seed.sql I have:

CREATE TABLE "User_x_Message"
(
"senderID" UUID NOT NULL,
"recipientID" UUID NOT NULL,
"messageID" UUID NOT NULL,
"notifyRecipient" BOOL NOT NULL DEFAULT true,
"hideMediaMetadata" BOOL DEFAULT false,
downloaded BOOL DEFAULT false,
played BOOL DEFAULT false
);

So I gave up on seed data and removed the INSERT statements from seed.sql, and restarted. This time supabase started up without issue.

Then (in a database tool's terminal window), I executed the exact INSERT statements I'd previously had in seed.sql, and they worked without issue. So it appears we have a problem with seed.sql, in that table definitions must be included... but if they are, seed-data inserts fail.

Stokestack avatar Oct 09 '24 08:10 Stokestack

Fortunately I had not tried the DB reset yet, so I can try the tests you requested.

Restarting after supabase stop --no-backup failed, because I only had seed-data INSERTs in seed.sql, not table creation. So my custom DB tables were missing.

So I added table-drop & creation at the top of seed.sql. Now I'm getting

failed to send batch: ERROR: column "messageID" of relation "User_x_Message" does not exist (SQLSTATE 42703)

Which is wrong, because at the top of seed.sql I have:

CREATE TABLE "User_x_Message"
(
"senderID" UUID NOT NULL,
"recipientID" UUID NOT NULL,
"messageID" UUID NOT NULL,
"notifyRecipient" BOOL NOT NULL DEFAULT true,
"hideMediaMetadata" BOOL DEFAULT false,
downloaded BOOL DEFAULT false,
played BOOL DEFAULT false
);

So I gave up on seed data and removed the INSERT statements from seed.sql, and restarted. This time supabase started up without issue.

Then (in a database tool's terminal window), I executed the exact INSERT statements I'd previously had in seed.sql, and they worked without issue. So it appears we have a problem with seed.sql, in that table definitions must be included... but if they are, seed-data inserts fail.

Indeed, seed.sql should not include any schema changes such as CREATE TABLE or DROP TABLE instructions, those should be scoped in migrations files and seed should be the place where the INSERT INTO lives.

avallete avatar Oct 09 '24 08:10 avallete

Thanks for the confirmation.

Stokestack avatar Oct 09 '24 20:10 Stokestack