Realtime fails on supabase cli v1.112.0

[gabrielpfl]

Describe the bug During local development, realtime fails to initialize with Could not create schema migrations table.

To Reproduce Steps to reproduce the behavior:

1. Install supabase 1.112.0
2. supabase start
3. Observe log failure in console output

Expected behavior Realtime should work in local development.

Screenshots N/A

Desktop (please complete the following information):

• OS: macOS Sonoma (14.1)
• Browser (if applicable) [e.g. chrome, safari]
• Version of CLI: 1.112.0
• Version of supabase-js (if applicable) [e.g. v2.22.0]
• Version of Node.js: 18.18.2

Additional context Error log:

realtime-dev.supabase_realtime_biblio container logs:
14:05:09.866 [error] Could not create schema migrations table. This error usually happens due to the following:

  * The database does not exist
  * The "schema_migrations" table, which Ecto uses for managing
    migrations, was defined by another library
  * There is a deadlock while migrating (such as using concurrent
    indexes with a migration_lock)

To fix the first issue, run "mix ecto.create".

To address the second, you can run "mix ecto.drop" followed by
"mix ecto.create". Alternatively you may configure Ecto to use
another table and/or repository for managing migrations:

    config :realtime, Realtime.Repo,
      migration_source: "some_other_table_for_schema_migrations",
      migration_repo: AnotherRepoForSchemaMigrations

The full error report is shown below.

** (Postgrex.Error) ERROR 3F000 (invalid_schema_name) no schema has been selected to create in
    (ecto_sql 3.8.3) lib/ecto/adapters/sql.ex:932: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.14.3) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
    (ecto_sql 3.8.3) lib/ecto/adapters/sql.ex:1024: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:696: Ecto.Migrator.verbose_schema_migration/3
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:510: Ecto.Migrator.lock_for_migrations/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:422: Ecto.Migrator.run/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:146: Ecto.Migrator.with_repo/3
    nofile:1: (file)

[soedirgo]

Does this get resolved after running docker volume prune -a? (P.S. make sure to save any local schema changes as migrations before running this)

[gabrielpfl]

No, it's still showing the same error. I have tried to delete images, containers, volumes and cache from docker. Seems like is being cached somewhere I don't know. This error happened after linking my local project with my supabase project at https://supabase.com/dashboard/. I followed the doc at https://supabase.com/docs/guides/cli/local-development#deploy-your-project. After supabase migration up I did supabase stop and that's when the problem started. Since then I cannot supabase start

[filipecabaco]

We pushed a fix that potential fixes this. A seed file had a wrong configuration hence it was impossible for it to create migrations.

https://github.com/supabase/cli/pull/1672

[johnborillo]

@gabrielpfl Hey were you able to solve the issue? Im encountering the same issue using supabase start after linking my local environment the the remote one. I followed the same docs and still getting the errors.

Specs: OS: macOS Ventura Browser (if applicable) [e.g. chrome, safari]: Chrome Version of CLI: 1.113.2

[filipecabaco]

Did a test and indeed linking seems to not work as expected due to the tenant name set during the linking process. Checking what is needed to open a PR with a fix 👀

[filipecabaco]

ok I was running an older version 🤦 ran with version 1.115.4 and worked as expected.

@johnborillo are you able to drop the volumes from docker and try to run db dump again?

[gabrielpfl]

@johnborillo no. I just upgraded supabase to version 1.115.4 and after deleting everything in docker, even after docker system prune -a, is still showing the same error.

18:28:33.148 [error] Could not create schema migrations table. This error usually happens due to the following:

  * The database does not exist
  * The "schema_migrations" table, which Ecto uses for managing
    migrations, was defined by another library
  * There is a deadlock while migrating (such as using concurrent
    indexes with a migration_lock)

To fix the first issue, run "mix ecto.create".

To address the second, you can run "mix ecto.drop" followed by
"mix ecto.create". Alternatively you may configure Ecto to use
another table and/or repository for managing migrations:

    config :realtime, Realtime.Repo,
      migration_source: "some_other_table_for_schema_migrations",
      migration_repo: AnotherRepoForSchemaMigrations

The full error report is shown below.

** (Postgrex.Error) ERROR 3F000 (invalid_schema_name) no schema has been selected to create in
    (ecto_sql 3.8.3) lib/ecto/adapters/sql.ex:932: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.14.3) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
    (ecto_sql 3.8.3) lib/ecto/adapters/sql.ex:1024: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:696: Ecto.Migrator.verbose_schema_migration/3
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:510: Ecto.Migrator.lock_for_migrations/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:422: Ecto.Migrator.run/4
    (ecto_sql 3.8.3) lib/ecto/migrator.ex:146: Ecto.Migrator.with_repo/3
    nofile:1: (file)
service not healthy: [realtime-dev.supabase_realtime_biblio]

[filipecabaco]

@gabrielpfl could you try with docker system prune --all --volumes? Without it it might retain some of the volumes created.

[sweatybridge]

For those with linked projects, you might also need to delete supabase/.temp/realtime-version file to avoid patched version from being overridden by linked project.

[gabrielpfl]

After both recommendations it worked, thanks @sweatybridge and @filipecabaco !

[filipecabaco]

awesome! thank you for the patience, reporting and help debugging the issue 🙏

[i-am-the-slime]

@gabrielpfl could you try with docker system prune --all --volumes? Without it it might retain some of the volumes created.

What if I have important volumes in my docker unrelated to supabase?

[filipecabaco]

@i-am-the-slime you could also run the following: docker volume rm $(docker volume list | grep supabase | awk '{print $2}')

All volumes from CLI have a supabase prefix so this will list and remove volumes from stopped containers

[kurtguenther]

FWIW all I had to do was clear the .temp folder above as suggested by doing supabase unlink. I didn't have to do any volume killing.

[codentacos]

For those with linked projects, you might also need to delete supabase/.temp/realtime-version file to avoid patched version from being overridden by linked project.

Life saver. This fixed a similar issue I was having when just deleting docker volumes did not resolve the issue.