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
- Dump the raw response and confirm which inner type came back.
- Give each TursoConnection its own connection string and lifecycle; never share or replay session state across connections.
- Disable response caching on the pipeline route at any proxy layer.
- Upgrade both server and Turso.Data bindings to matching releases.
- 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
- Give every TursoConnection its own lifecycle; never reuse connection objects or session state across logical sessions.
- Disable response caching on the pipeline route at every proxy layer.
- Keep server and bindings versions aligned.
- When responses look crossed, capture the raw envelope before changing code.
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
- Remote request returned unexpected result type: {result.Type
- Remote close returned unexpected result type: {result.Type}
- Remote request returned no results.
- Remote request returned an empty ok response.
- Remote batch returned no results.
AI-assisted analysis of tursodatabase/turso@244cde92a7 (2026-08-20).
Data as JSON: /api/errors/cf49fd6bd96dd9fd.
Report an issue: GitHub.