`db shell` with bad hostname yields error 'unsupported protocol scheme "libsql"'

[CodingDoug]

$ turso db shell libsql://asdfasd.asd
Error: failed to run shell: failed to connect to database: Post "libsql://asdfasd.asd": unsupported protocol scheme "libsql"

The error message states incorrectly that libsql is not a supported scheme. The actual error is that the hostname wasn't found.

[luisfvieirasilva]

@CodingDoug, I've tested after this PR (that make it possible to use localhost again) and the behavior that I'm getting this:

go run ./cmd/turso/main.go db shell libsql://asdfasd.asd                                                            
Error: failed to connect to database

When trying with turso.io domain it tries for a long time to connect, eventually reaches the timeout and returns the same thing:

go run ./cmd/turso/main.go db shell libsql://asdfasd.turso.io                                                            
Error: failed to connect to database

Is taking long a problem that we should keep track? What do you think? If yes, should we use this issue to do that or I can close this and open a new one?

[CodingDoug]

@luisfvieirasilva So I just discovered that all hosts under .turso.io resolves with the same IP address. That's a very different situation than a host that doesn't resolve at all. It's good that the shell fails eventually, but maybe @athoscouto has some thoughts on how to make this better.

[athoscouto]

We have a *.turso.io DNS entry that serves as a fallback domain resolution. But every database has its $DB-$USER.turso.io domain that resolves to a unique IPv6 and a shared IPv4.

If you try to connect to not-found-domain.turso.io your request will be routed using the wildcard domain. The service that receives tries to find a database for it until it times out. It won't check if the database exists though, it assumes you know what you're doing. We may fix it by making sure it checks if the database exists. But we must be careful, this shouldn't increase the latency for databases that exist.

I'd rather fix it on the CLI by checking, before connecting to a turso.io database, if it exists. We had this logic before.

Also, since we're at it, turso db shell is not working when you try to connect to specific instances. It will just connect to the database, not the specific instance you were asking for.

[CodingDoug]

If i'm understanding this correctly @athoscouto there are a two things that we could do to improve the CLI here:

• Shell is currently not able to connect to a replica and only connects to the primary - we should instead allow this
• If the shell encounters a turso.io hostname, it should check to make sure the db exists first before connecting (this fixes the timeout problem). We need a good error message in this case.

And if the host isn't turso.io, just connect to it anyway, which is what we want for local development or other self-hosted sqld. That was the original issue.

[luisfvieirasilva]

@CodingDoug @athoscouto I've just created the two issues pointed on the discussion and I'm closing this one

• 450

• 451