What causes "Expected Turso sync result {expected}, got {actual}." in tursodatabase/turso?

Ensure the managed Turso.Data package and the native libturso bindings are the same version; upgrade/reinstall both together

tursodatabase/turso · error · InvalidOperationException

Expected Turso sync result {expected}, got {actual}.

Error message

Expected Turso sync result {expected}, got {actual}.

What it means

EnsureResultKind compares the result kind returned by the native sync bindings against the kind the calling code expected for the operation (e.g. frames vs. bootstrap) and throws this InvalidOperationException on mismatch. It signals an internal protocol/sequence bug: the native layer returned a different sync outcome than the managed state machine required at that point.

Source

Thrown at bindings/dotnet/src/Turso.Data/TursoSyncDatabase.cs:841

            RemoteEncryptionCipher = encryption?.NativeName,
            PushOperationsThreshold = options.PushOperationsThreshold is null
                ? 0
                : (nuint)options.PushOperationsThreshold.Value,
            PullBytesThreshold = options.PullBytesThreshold is null
                ? 0
                : (nuint)options.PullBytesThreshold.Value,
            LogicalMvccPull = options.ForceLogicalMvccPull,
            ExperimentalFeatures = options.ExperimentalFeatures,
        };
    }

    private static void EnsureResultKind(
        TursoSyncOperationHandle operation,
        TursoSyncOperationResultKind expected)
    {
        var actual = TursoSyncBindings.GetResultKind(operation);
        if (actual != expected)
            throw new InvalidOperationException($"Expected Turso sync result {expected}, got {actual}.");
    }

    private static DateTimeOffset? ToTimestamp(long value)
        => value <= 0 ? null : DateTimeOffset.FromUnixTimeSeconds(value);

    private TursoSyncException CreateSyncException(
        TursoSyncOperationKind operation,
        Exception exception)
    {
        var transport = _lastTransportContext;
        var message = RedactSecrets(exception.Message);
        var innerException = ContainsSecret(exception.ToString())
            ? new Exception(message)
            : exception;
        return new TursoSyncException(
            operation,
            $"Turso sync {operation} failed: {message}",
            (exception as TursoSyncNativeException)?.StatusCode,

View on GitHub (pinned to 6c72522679)

Solutions

Ensure the managed Turso.Data package and the native libturso bindings are the same version; upgrade/reinstall both together
Do not reuse TursoSyncOperationHandle across phases; complete or dispose the operation and start a fresh sync
Avoid calling sync operations concurrently on the same TursoSyncDatabase instance; serialize sync calls
If reproducible, file a bug with the expected/actual result kinds — this indicates a client protocol defect

Example fix

// before: reusing an operation handle across sync phases
var handle = db.BeginSync();
ProcessFrames(handle);
ProcessFrames(handle); // may now be a different result kind
// after: run one operation per phase
using var handle = db.BeginSync();
ProcessFrames(handle);

Defensive patterns

Strategy: try-catch

Validate before calling

// keep managed assembly and native libturso versions aligned
var expected = typeof(TursoSyncDatabase).Assembly.GetName().Version;
// assert against your deployment's native binding version before syncing

Try / catch

try
{
    await db.SyncAsync(ct);
}
catch (InvalidOperationException ex) when (ex.Message.Contains("Expected Turso sync result"))
{
    logger.LogError(ex, "Native sync bindings returned an unexpected result kind; check version alignment and single-threaded sync usage.");
    throw;
}

Prevention

Pin and deploy the managed package and native bindings as one matched unit
Never call sync APIs on the same TursoSyncDatabase from multiple threads; serialize sync operations
Do not reuse sync operation handles across phases; complete each operation before starting another

When it happens

Trigger: A sync operation whose TursoSyncOperationHandle returns a result kind from TursoSyncBindings.GetResultKind that differs from the expected kind for the current step — e.g. expecting a frames result but the native side returned a bootstrap or error-pending kind, or reusing a handle after a state change.

Common situations: Version mismatch between the managed Turso.Data assembly and the native libturso sync bindings; calling sync APIs out of order (e.g. continuing a partial sync session in the wrong phase); concurrency bugs where one thread advances the operation before another checks its result.

Related errors

AI-assisted analysis of tursodatabase/turso@6c72522679 (2026-08-31). Data as JSON: /api/errors/d485e85a7a643935. Report an issue: GitHub.