Getting started with CLI does not work (start, login)

[samtay]

Describe the bug I just started using supabase, and my experience with this CLI has been inauspicious.

1. supabase login doesn't work for me.. I get the browser opened up with a success message, but back in the terminal I'm stuck on Your token is now being generated and securely encrypted. Waiting for it to arrive.... I was able to get around this by manually creaking a token in the dashboard and supplying it via supabase login --token.
2. supabase start fails as well (with no error messages). Running with --debug I can see some logs but they are really terribly formatted:
3. There should be an option to not remove the containers upon failure. But, by running docker container ps before the containers get automatically removed I was able to docker container attach to see this realtime error:

   ** (ErlangError) Erlang error: {:erpc, :timeout}
   (kernel 9.2.4) erpc.erl:714: :erpc.call/5
   (stdlib 5.2.3) timer.erl:270: :timer.tc/2
   (realtime 2.29.13) lib/realtime/rpc.ex:37: Realtime.Rpc.enhanced_call/5
   (realtime 2.29.13) lib/realtime/tenants.ex:85: Realtime.Tenants.health_check/1
   nofile:2: (file)
   (stdlib 5.2.3) erl_eval.erl:750: :erl_eval.do_apply/7
   (stdlib 5.2.3) erl_eval.erl:494: :erl_eval.expr/6
   [os_mon] memory supervisor port (memsup): Erlang has closed
   [os_mon] cpu supervisor port (cpu_sup): Erlang has closed

4. Unfortunately, this error happens even if I pass -x realtime.
5. Running the commands with --create-ticket did not output the sys info required below.

To Reproduce Steps to reproduce the behavior:

1. Download the CLI and try basic things from the "Getting Started" documentation.

Expected behavior Things should just work. If they don't, appropriate errors should be visible.

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

• Ticket ID: none
• Version of OS: Arch Linux
• Version of CLI: I've tried both the current release 1.178.2 and the beta 1.179.3.
• Version of Docker: 26.1.4
• Versions of services:

      SERVICE IMAGE      │      LOCAL       │ LINKED
  ─────────────────────────┼──────────────────┼─────────
  supabase/postgres      │ 15.1.1.61        │ -
  supabase/gotrue        │ v2.151.0         │ -
  postgrest/postgrest    │ v12.2.0          │ -
  supabase/realtime      │ v2.29.13         │ -
  supabase/storage-api   │ v1.0.6           │ -
  supabase/edge-runtime  │ v1.54.9          │ -
  supabase/studio        │ 20240422-5cf8f30 │ -
  supabase/postgres-meta │ v0.80.0          │ -
  supabase/logflare      │ 1.4.0            │ -
  supabase/supavisor     │ 1.1.56           │ -
  darthsim/imgproxy      │ v3.8.0           │ -

Additional context If applicable, add any other context about the problem here.

• Browser: Firefox
• Version of supabase-js: none
• Version of Node.js: not applicable

[samtay]

Update: the core issues (1) and (2) above were solved by connecting to a different wifi network, so those are likely duplicates of #2455 . If it helps narrow things down, I also noticed some strange behavior before switching wifi networks: the CLI would have very long pauses. Even supabase --help would print help and then the command wouldn't actually finish executing for another 10s or so - perhaps it is trying to do something with a network connection by default?

The other bits above IMO are still relevant - improved logging and error reporting, option to persist containers, and not requiring a realtime container if -x realtime is passed. Feel free to close at your discretion.

[sweatybridge]

Even supabase --help would print help and then the command wouldn't actually finish executing for another 10s or so

This is because the cli checks for any updates on startup. I can probably reduce the timeout here to make it respond faster.

not requiring a realtime container if -x realtime is passed

The realtime container still needs to run to apply schema migrations, even if it's not started. This is ensure your local schema matches hosted project.

The logs display issue seems to happen randomly for me. I will take a closer look at that.

[sweatybridge]

Could you also report which shell you are using? This is to help me reproduce the login issue.

[samtay]

Sure: zsh 5.9 (x86_64-pc-linux-gnu)

[sweatybridge]

Updates on this issue:

1. It might be a duplicate of https://github.com/supabase/cli/issues/2447
2. I'm still looking into it, but it doesn't seem like a high priority.
3. It should be fixed by latest realtime image.
4. If not, it's now possible to disable realtime completely in supabase/config.toml.
5. This is working as intended because the flag submits a sentry ticket, not to print out the version info.

The problem with --help taking a long time when offline is also resolved in beta release, ie. npx supabase@beta start.