What causes "{operation} returned unexpected result type: {result.Type}" in tursodatabase/turso?

Capture the raw envelope and look at the second entry's type field to identify which layer produced it.

tursodatabase/turso · error · TursoException

{operation} returned unexpected result type: {result.Type}

Error message

{operation} returned unexpected result type: {result.Type}

What it means

When a statement or batch is sent with a trailing close request (closeAfter), the response should hold at most two entries: the statement/batch result and a close acknowledgment. ValidateOptionalTrailingClose threw because the trailing entry's type is neither "ok" nor "error" -- an unrecognized extra result where the close ack should be.

Source

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

    {
        if (response.Results.Count == 1)
            return;
        if (response.Results.Count > 2)
            throw new TursoException($"{operation} returned too many results.");

        var result = response.Results[1];
        switch (result.Type)
        {
            case "ok":
                if (result.Response?.Type != "close")
                    throw new TursoException($"{operation} returned unexpected response type: {result.Response?.Type}");
                break;

            case "error":
                break;

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

    private static List<RemoteStatementResult> ExtractBatchStepResults(RemoteBatchResult batch, int expectedCount)
    {
        if (batch.StepErrors.Count != expectedCount || batch.StepResults.Count != expectedCount)
        {
            throw new TursoException(
                $"Remote batch returned an unexpected result shape: {batch.StepResults.Count} results, {batch.StepErrors.Count} errors, expected {expectedCount}.");
        }

        for (var i = 0; i < batch.StepErrors.Count; i++)
        {
            if (batch.StepErrors[i] is { } error)
                throw CreateRemoteError(error);
        }

        var statementResults = new List<RemoteStatementResult>(expectedCount);

View on GitHub (pinned to 244cde92a7)

Solutions

Capture the raw envelope and look at the second entry's type field to identify which layer produced it.
Upgrade server and Turso.Data bindings to matching versions.
Avoid middleware that appends or reorders entries in pipeline responses.
If you control the server, ensure close requests are answered with ok/close or error entries only.
Report the unexpected entry shape with the raw envelope attached.

Defensive patterns

Strategy: try-catch

Try / catch

try { await cmd.ExecuteNonQueryAsync(cancellationToken); }
catch (TursoException ex) when (ex.Message.Contains("returned unexpected result type"))
{
    logger.LogError(ex, "Trailing close ack malformed after {Sql}", cmd.CommandText);
    throw;
}

Prevention

Upgrade bindings and server together so close-ack shapes stay compatible.
Do not append or reorder entries in pipeline responses at any middleware layer.
When self-hosting, answer close requests strictly with ok/close or error entries.
Capture the full envelope (including the trailing entry) when reporting.

When it happens

Trigger: Executing a command or batch on a remote connection in a mode that appends a close request (for example connection-close-after-execute paths): the response has exactly two entries and response.Results[1].Type falls outside ok/error. The operation string in the message tells you whether it came from 'Remote request' or 'Remote batch'.

Common situations: Server version drift that queues or reorders pipeline results; a server that injects extra entries (session/store results) the bindings do not expect; intermediaries appending entries to the results array.

Related errors

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