tursodatabase/turso · error · TursoException

Remote request returned unexpected result type: {result.Type

Error message

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

What it means

The top-level pipeline result entry had a type the client does not recognize. ExtractExecuteResult only accepts "ok" and "error" for single-statement execution; anything else (a future result kind, a typo, or garbage from an intermediary) hits the default branch and throws.

Source

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

            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.");

        var result = response.Results[0];
        List<RemoteStatementResult> statementResults;
        switch (result.Type)
        {
            case "ok":
                if (result.Response is null)
                    throw new TursoException("Remote batch returned an empty ok response.");

View on GitHub (pinned to 244cde92a7)

Solutions

Capture the raw envelope and identify the unknown type string and which layer produced it.
If the server is newer than the bindings, upgrade the Turso.Data package to a release that supports the result type.
If an intermediary injects entries, remove it from the pipeline route.
If you operate the server, make it emit only ok/error entries as the protocol requires.
Report the unknown type to the bindings maintainers with the raw envelope.

Defensive patterns

Strategy: try-catch

Try / catch

try { await cmd.ExecuteNonQueryAsync(cancellationToken); }
catch (TursoException ex) when (ex.Message.Contains("unexpected result type"))
{
    logger.LogError(ex, "Unknown pipeline entry type for {Sql} -- likely version skew", cmd.CommandText);
    throw;
}

Prevention

Upgrade the Turso.Data package whenever the server is upgraded; new entry types arrive with server releases.
Do not let middleware inject entries into pipeline response arrays.
If you run a custom server, emit only ok/error entries.
Track the raw type string from the message when reporting issues.

When it happens

Trigger: Remote statement execution where response.Results[0].Type is neither "ok" nor "error" -- for example a server or proxy injecting entries with another type string.

Common situations: A newer server introduces a new result type that the installed (older) bindings do not know; a middleware layer injects health-check or audit entries into the results array; a custom /v2/pipeline implementation emits nonstandard type strings.

Related errors

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