tursodatabase/turso · error · TursoException

Remote request returned unexpected response type: {result.Re

Error message

Remote request returned unexpected response type: {result.Response.Type}

What it means

The first pipeline result was ok, but its inner response object had a type other than "execute" (for example "batch" or "close"). The client submitted a single statement execution, so any other inner type means the reply does not correspond to the request that was sent.

Source

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

        }

        return statement;
    }

    private static RemoteStatementResult ExtractExecuteResult(RemotePipelineResponse response)
    {
        if (response.Results.Count == 0)
            throw new TursoException("Remote request returned no results.");

        var result = response.Results[0];
        RemoteStatementResult statementResult;
        switch (result.Type)
        {
            case "ok":
                if (result.Response is null)
                    throw new TursoException("Remote request returned an empty ok response.");
                if (result.Response.Type != "execute")
                    throw new TursoException($"Remote request returned unexpected response type: {result.Response.Type}");
                statementResult = result.Response.DeserializeResult<RemoteStatementResult>();
                break;

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

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

        ValidateOptionalTrailingClose(response, "Remote request");
        return statementResult;
    }

    private static IReadOnlyList<RemoteStatementResult> ExtractBatchResults(RemotePipelineResponse response, int expectedCount)
    {
        if (response.Results.Count == 0)
            throw new TursoException("Remote batch returned no results.");

View on GitHub (pinned to 244cde92a7)

Solutions

  1. Dump the raw response and confirm which inner type came back.
  2. Give each TursoConnection its own connection string and lifecycle; never share or replay session state across connections.
  3. Disable response caching on the pipeline route at any proxy layer.
  4. Upgrade both server and Turso.Data bindings to matching releases.
  5. Report with the raw envelope if current versions still mismatch.
Defensive patterns

Strategy: try-catch

Try / catch

try { return await cmd.ExecuteReaderAsync(cancellationToken); }
catch (TursoException ex) when (ex.Message.Contains("unexpected response type"))
{
    logger.LogError(ex, "Reply/request mismatch for {Sql} -- check session sharing and versions", cmd.CommandText);
    throw;
}

Prevention

When it happens

Trigger: Remote TursoCommand execution where response.Results[0].Response.Type != "execute": the server answered with a batch-shaped or close-shaped payload, or responses were reordered/cross-wired.

Common situations: Server/client version drift changing the response envelope; a stateful session (baton) reused across connections that should have had separate sessions; middleware that caches or reorders pipeline responses; custom servers implementing /v2/pipeline incorrectly.

Related errors


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