tursodatabase/turso · error · InvalidOperationException

Unsupported remote Turso URL scheme: {uri.Scheme}

Error message

Unsupported remote Turso URL scheme: {uri.Scheme}

What it means

The switch in GetRemoteUri() throws this when the URL scheme is not libsql/http/https/ws/wss. In the current code it is effectively defensive dead code: the same five schemes were already accepted case-insensitively by IsRemoteScheme() earlier in the method, so a well-behaved call cannot reach it. If you do see it, the scheme check set and the switch have drifted apart (e.g. after a partial edit or version mismatch between compiled units).

Source

Thrown at bindings/dotnet/src/Turso.Data/TursoConnectionOptions.cs:148

        if (!Uri.TryCreate(DataSource, UriKind.Absolute, out var uri) || !IsRemoteScheme(uri.Scheme))
            throw new InvalidOperationException($"Data Source is not a remote Turso URL: {DataSource}");

        if (!string.IsNullOrEmpty(uri.Query) || !string.IsNullOrEmpty(uri.Fragment))
            throw new InvalidOperationException("Remote Turso URLs must not include query strings or fragments.");
        if (!string.IsNullOrEmpty(uri.UserInfo))
            throw new InvalidOperationException("Remote Turso URLs must not include embedded user information; use Auth Token instead.");
        if (string.IsNullOrEmpty(uri.Host))
            throw new InvalidOperationException("Remote Turso URLs must include a host.");

        var scheme = uri.Scheme.ToLowerInvariant() switch
        {
            "libsql" => Tls == false ? "http" : "https",
            "turso" => ValidateTls(uri.Scheme, expectedTls: true, normalizedScheme: "https"),
            "http" => ValidateTls(uri.Scheme, expectedTls: false),
            "https" => ValidateTls(uri.Scheme, expectedTls: true),
            "ws" => ValidateTls(uri.Scheme, expectedTls: false, normalizedScheme: "http"),
            "wss" => ValidateTls(uri.Scheme, expectedTls: true, normalizedScheme: "https"),
            _ => throw new InvalidOperationException($"Unsupported remote Turso URL scheme: {uri.Scheme}")
        };

        var builder = new UriBuilder(uri)
        {
            Scheme = scheme,
            Port = uri.IsDefaultPort ? -1 : uri.Port,
            UserName = string.Empty,
            Password = string.Empty,
        };

        return builder.Uri;
    }

    public static TursoConnectionOptions Parse(string connectionString)
    {
        return new TursoConnectionOptions(new TursoConnectionStringBuilder(connectionString));
    }

View on GitHub (pinned to 6c72522679)

Solutions

1. Verify you are not loading mixed versions of the Turso assemblies (clean bin/obj, reinstall the Turso.Data package).
2. Confirm the URL scheme really is one of libsql, http, https, ws, wss (spelled exactly).
3. If it reproduces on the latest package, report it — the switch and IsRemoteScheme have drifted in the library.

// Practically unreachable: IsRemoteScheme already gates the same schemes.
// If hit, verify assembly versions match:
typeof(TursoConnectionOptions).Assembly.GetName().Version.Dump();

When it happens

Trigger: Not reachable through the public API today because IsRemoteScheme(uri.Scheme) already gates the exact same scheme list with OrdinalIgnoreCase comparison; it could only fire if IsRemoteScheme were extended with a new scheme without updating this switch, or if mismatched assembly versions are loaded.

Common situations: Essentially never in shipped code; a report of it usually indicates stale/mixed assembly versions in the output folder (an old Turso.Data DLL paired with a newer dependency) rather than a user configuration error.

Related errors

• Data Source is not a remote Turso URL: {DataSource}
• Remote Turso URLs must not include query strings or fragment
• Remote Turso URLs must not include embedded user information
• Remote Turso URLs must include a host.
• Embedded replica connections are not supported yet by the .N

AI-assisted analysis of tursodatabase/turso@6c72522679 (2026-08-20). Data as JSON: /api/errors/10d200d3c0576995. Report an issue: GitHub.