'db reset' fails to respect prior '--network-id' configuration, causing split-brain network state

[NiikhilRaj]

Describe the bug

When a project is started using a custom Docker network (supabase start --network-id <name>), running supabase db reset without re-specifying the --network-id flag causes the database to be recreated on the default network (supabase_network_<project>).

However, the other services (Kong, Auth, Storage, etc.) remain running on the custom network. This results in a "split-brain" network state where dependent services cannot resolve the database hostname (db or supabase_db_<id>), leading to ENOTFOUND errors.

The CLI appears to lack state persistence for the network configuration or a "look before you leap" mechanism to inspect the existing database's network before resetting it.

To Reproduce

Steps to reproduce the behavior:

1. Initialize a Supabase project.
2. Create a custom Docker network:

   docker network create <network-name>

3. Start Supabase on this network:

   supabase start --network-id <network-name>

4. The Trigger: Run reset without the flag:

   supabase db reset

5. Observation: The command succeeds, but shortly after, services log connection errors.

Expected behavior

supabase db reset should infer the correct network ID by either:

1. Inspecting the currently running database container before removing it.
2. Or persisting the --network-id configuration used during start.

Screenshots / Logs

Services fail with DNS resolution errors because the database hostname no longer exists on their network:

{
  "level": 50,
  "type": "startupError",
  "error": {
    "code": "ENOTFOUND",
    "syscall": "getaddrinfo",
    "hostname": "supabase_db_<network-name>"
  },
  "msg": "Server not started with error"
}

System information

• OS: Windows 11 (24H2)
• Supabase CLI Version: 2.67.2
• Docker Version: 27.4.0

Additional context

I have analyzed the behavior locally.

1. Workaround: Running supabase db reset --network-id <network-name> works correctly.
2. Analysis: It appears reset.go initializes a new NetworkingConfig using utils.NetId. If the flag is not present in the current command, utils.NetId defaults to the generated network name (supabase_network_<project_id>) rather than the active custom network.

Proposed Solution:
In internal/db/reset/reset.go, we should inspect the existing container using utils.Docker.ContainerInspect to retrieve its NetworkSettings before the ContainerRemove step. This Network ID should then be used for the subsequent DockerStart command.

Update: I am currently working on a Pull Request to implement this fix.

[opxdelwin]

This would make sense. If I try to run supabase start 2 times, it just returns the keys/details for currently running instance. This patch does make sense..