sweatybridge
commented
1 week ago 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.
Open ThingEngineer opened 1 week ago
sweatybridge
commented
1 week ago 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
commented
1 week ago Could you try
supabase stop --no-backupfollowed by start? We switched to a new initialization routine that's not compatible with local db state.
Tried and failed, started with health checked disabled and tried to start normally again after stop --no-backup but still fails. Maybe if I had stoped that way before the upgrade?
I'd rather not re-init the CLI if it can be avoided, any other ideas to get analytics back?
evelant
commented
1 week ago @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.
ThingEngineer
commented
1 week ago @ThingEngineer I started with analytics.enabled = false then did
supabase db resetand that worked for me to create the missing database and schemas. Obviously this removes all your local data.
Good to hear, I was in the process of making sure my seed data was up to date so I could try that.
I also tried supabase-beta:
brew unlink supabase
brew install supabase/tap/supabase-beta
brew link supabase-beta
brew upgrade supabase-betaBut the issue persisted there so I switched back.
avallete
commented
1 week ago 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;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;
✅FIX #2737, #2742 This worked, used psql tool in pgAdmin to connect. Supabase starts normally and analytics are back online.
psql (16.0, server 15.1 (Ubuntu 15.1-1.pgdg20.04+1))
Type "help" for help.
postgres=> CREATE DATABASE _supabase WITH OWNER postgres;
CREATE DATABASE
postgres=> \c _supabase
psql (16.0, server 15.1 (Ubuntu 15.1-1.pgdg20.04+1))
You are now connected to database "_supabase" as user "postgres".
_supabase=> CREATE SCHEMA IF NOT EXISTS _analytics;
CREATE SCHEMA
_supabase=> ALTER SCHEMA _analytics OWNER TO postgres;
ALTER SCHEMA
_supabase=> CREATE SCHEMA IF NOT EXISTS _supavisor;
CREATE SCHEMA
_supabase=> ALTER SCHEMA _supavisor OWNER TO postgres;
ALTER SCHEMA
_supabase=> \qOn another project I fixed this by deleting all of the supabase_* docker volumes so that supabase start reinitialized the db from /migrations and seed.sql. (Note that you'll loose your storage files doing this.)
A little breaking change warning would have been nice but in all fairness, following the recommended upgrade procedure in the docs would have prevented this.
t1mmen
commented
1 week ago This remains an issue on v1.204.3. Thanks to the comments above, I resolved it by:
analytics in config.toml.$ supabase start$ supabase db reset$ supabase stopanalytics in config.toml.$ supabase startI did try manually creating the schema (after step #2), as describe here, but that did not work for me.
ThingEngineer
commented
1 week ago @t1mmen Curious. I think the initial issue is obviously upgrading the CLI without first stopping supabase with the no back up flag (verified on other projects). And it seems whether or not you have an analytics enabled at that time makes a difference as well.
The group of various fixes all seem to work eventually, but in different combinations for different projects.
t1mmen
commented
1 week ago @ThingEngineer That sounds right. Our dev setup script (snippet below for reference) does stop the db, but using supabase stop --backup behind the db:stop command)
async function ensureSupabaseInstalled() {
const result = await checkCommand('supabase --version');
if (result) {
const version = result.match(/\d+\.\d+\.\d+/)?.[0] || 'unknown';
if (semver.gte(version, '1.204.3')) {
console.log(
`🟢 ${chalk.bold('supabase')} is installed with an acceptable version (${version}).`
);
} else {
console.log(
`⚡ ${chalk.bold(
'supabase'
)} is installed but the version is too old (${version}). Updating...`
);
await runYarnTask('db:stop', 'stopping supabase before updating to latest version...');
await execaCommand('brew upgrade supabase/tap/supabase', { stdio: 'inherit' });
console.log(`✓ ${chalk.bold('supabase')} updated to a newer version.`);
console.log(
`⚡ ${chalk.bold('In case of issues')} you may need to wipe the database via ${chalk.bold(
'yarn db:reset'
)} -- sorry!`
);
}
} else {
console.log(`⚡ ${chalk.bold('supabase')} is not installed. Installing...`);
await execaCommand('brew update', { stdio: 'inherit' });
await execaCommand('brew install supabase/tap/supabase', { stdio: 'inherit' });
console.log(`✓ ${chalk.bold('supabase')} installed.`);
}
}FWIW, it'd be nice if "Backup and stop running containers" step was baked into upgrade process in a nicer way (so as to not clutter up seed.sql which might be accidentally committed)
PS: This is the first time I recall getting into a state which could not be resolved with a supabase db reset after upgrade, after almost 2 years using Supabase.
ThingEngineer
commented
2 days ago it'd be nice if "Backup and stop running containers" step was baked into upgrade process in a nicer way (so as to not clutter up
seed.sqlwhich might be accidentally committed).
Agreed, that is an issue when using branching. Just something us wildcard people will have to add to the cognitive load for the time.
Also, same on the db reset after update. But having access to the code base makes for a pretty quick fix on most issues.
marcelorl
commented
2 days ago I just cant believe this is an issue. OH MY.
Describe the bug v1.203.0 will not start without either:
disabling health checks
supabase start --ignore-health-checkor disabling analytics
To Reproduce Steps to reproduce the behavior:
supabase stopsupabase startExpected behavior Supabase passes all health checks and starts.
System information
Additional context If applicable, add any other context about the problem here.
supabase link, stoped supabase restarted the host OS, docker, then attempted a normalsupabase startagain with no joy.