v1.203.0 - Supabase CLI analytics is not healthy #2737
Comments
|
Could you try |
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? |
|
@ThingEngineer I started with analytics.enabled = false then did |
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: But the issue persisted there so I switched back. |
|
Another possibility to keep your local data would be to manually connect to the database container and manually run the migration: |
✅FIX #2737, #2742 On another project I fixed this by deleting all of the 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. |
|
This remains an issue on v1.204.3. Thanks to the comments above, I resolved it by:
I did try manually creating the schema (after step #2), as describe here, but that did not work for me. |
|
@t1mmen Curious. The group of various fixes all seem to work eventually, but in different combinations for different projects. |
|
@ThingEngineer That sounds right. Our dev setup script (snippet below for reference) does stop the db, but using 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 PS: This is the first time I recall getting into a state which could not be resolved with a |
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 |
|
I just cant believe this is an issue. OH MY. |
|
Unfortuantely @t1mmen's steps above didn't fix these errors for me. I had to delete any old supabase docker containers as a previous comment mentioned. I did that with the following commands:
|
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.The text was updated successfully, but these errors were encountered: