tursodatabase/turso · error · TursoException

Remote close returned unexpected result type: {result.Type}

Error message

Remote close returned unexpected result type: {result.Type}

What it means

While validating the response to a close request, the client found a top-level result entry whose type is neither "ok" nor "error". ValidateCloseResult iterates every entry in the close response, so any unknown type string aborts connection close.

Source

Thrown at bindings/dotnet/src/Turso.Data/TursoRemoteClient.cs:337

        return statementResults;
    }

    private static void ValidateCloseResult(RemotePipelineResponse response)
    {
        foreach (var result in response.Results)
        {
            switch (result.Type)
            {
                case "ok":
                    if (result.Response?.Type is not "close")
                        throw new TursoException($"Remote close returned unexpected response type: {result.Response?.Type}");
                    break;

                case "error":
                    throw CreateRemoteError(result.Error);

                default:
                    throw new TursoException($"Remote close returned unexpected result type: {result.Type}");
            }
        }
    }

    private static TursoException CreateRemoteError(RemoteError? error)
    {
        if (error is null)
            return new TursoRemoteSqlException("Remote SQL execution failed.");

        return string.IsNullOrWhiteSpace(error.Code)
            ? new TursoRemoteSqlException($"Remote SQL execution failed: {error.Message}")
            : new TursoRemoteSqlException($"Remote SQL execution failed: {error.Message} ({error.Code})");
    }

    private void UpdateSession(RemotePipelineResponse response, bool closeAfter)
    {
        if (!string.IsNullOrWhiteSpace(response.BaseUrl))
        {

View on GitHub (pinned to 244cde92a7)

Solutions

Capture the raw close-response envelope and identify the unknown type string.
Upgrade the Turso.Data bindings to a version matching the server.
If an intermediary injects entries, take it off the pipeline route.
Make close failures non-fatal in disposal paths (see the close-safe finally pattern) while you upgrade.

Defensive patterns

Strategy: try-catch

Try / catch

try { await conn.CloseAsync(cancellationToken); }
catch (TursoException ex) when (ex.Message.Contains("Remote close returned unexpected result type"))
{
    logger.LogWarning(ex, "Unknown entry type in close response; upgrading bindings likely required");
}

Prevention

Upgrade Turso.Data bindings in lockstep with server upgrades.
Keep middleware from injecting entries into close responses.
Treat close/Dispose-time exceptions as diagnostic signals, not data failures -- separate the two in code.
Capture the raw close envelope when reporting the unknown type.

When it happens

Trigger: Closing/disposing a remote TursoConnection with an open session where a response entry's Type is outside ok/error -- for example a future entry kind the bindings do not recognize.

Common situations: Newer server emitting new entry types on close that older bindings reject; middleware injecting entries; custom /v2/pipeline implementations; the exception surfacing from Dispose in 'await using' blocks.

Related errors

AI-assisted analysis of tursodatabase/turso@244cde92a7 (2026-08-20). Data as JSON: /api/errors/bc48ca22d320ad69. Report an issue: GitHub.