What causes "Zstd encoding is not supported" in tursodatabase/turso?

Set encoding to Raw (0) or omit the field when talking to this server.

Zstd encoding is not supported

Error message

Zstd encoding is not supported

What it means

The `encoding` field of PullUpdatesReqProtoBody selects how page payloads are compressed. This test server implements only the Raw encoding and refuses an explicit Zstd request with HTTP 500 rather than silently returning an unexpected format. Unknown enum values are quietly coerced to Raw (try_from(...).unwrap_or(Raw)), so this fires only on a genuine Zstd request.

Source

Thrown at cli/sync_server.rs:499

                query_duration_ms: 0.0,
            })
        }
    }

    fn handle_pull_updates(&self, body: &[u8]) -> Result<HttpResponse> {
        let req = <PullUpdatesReqProtoBody as Message>::decode(body)
            .map_err(|e| anyhow!("Failed to decode PullUpdatesRequest: {}", e))?;

        debug!(
            "Pull updates request: server_revision={}, client_revision={}",
            req.server_revision, req.client_revision
        );

        let encoding =
            PageUpdatesEncodingReq::try_from(req.encoding).unwrap_or(PageUpdatesEncodingReq::Raw);

        if encoding == PageUpdatesEncodingReq::Zstd {
            return Err(anyhow!("Zstd encoding is not supported"));
        }

        if PullUpdatesStreamKind::try_from(req.stream_kind).unwrap_or(PullUpdatesStreamKind::Pages)
            == PullUpdatesStreamKind::MvccLogicalLog
        {
            return self.handle_logical_pull_updates(&req);
        }

        self.handle_page_pull_updates(&req, PullUpdatesApplyMode::Incremental)
    }

    fn handle_page_pull_updates(
        &self,
        req: &PullUpdatesReqProtoBody,
        apply_mode: PullUpdatesApplyMode,
    ) -> Result<HttpResponse> {
        let conn = self.conn.lock().unwrap();

View on GitHub (pinned to bad083fafb)

Solutions

Set encoding to Raw (0) or omit the field when talking to this server.
Point the zstd-configured client at a production sync endpoint that supports it.
If you own both ends, implement zstd encode/decode in the server's page response path and the client apply path.

Example fix

// before
let req = PullUpdatesReqProtoBody { encoding: PageUpdatesEncodingReq::Zstd as i32, ..req.clone() };

// after
let req = PullUpdatesReqProtoBody { encoding: PageUpdatesEncodingReq::Raw as i32, ..req.clone() };

Defensive patterns

Strategy: validation

Validate before calling

if PageUpdatesEncodingReq::try_from(req.encoding) != Ok(PageUpdatesEncodingReq::Raw) {
    // local sync server supports Raw only
    req.encoding = PageUpdatesEncodingReq::Raw as i32;
}

Try / catch

On 500 'Zstd encoding is not supported', re-issue the pull with encoding=Raw (0) instead of retrying unchanged.

Prevention

Check which encodings an endpoint supports before enabling compression on the client.
Gate zstd behind a server capability flag, not a client-only config option.

When it happens

Trigger: A /pull-updates request with encoding = PageUpdatesEncodingReq::Zstd, typically from a client SDK configured for compressed sync.

Common situations: Enabling zstd on mobile or bandwidth-limited clients and then testing against the local tursodb sync server; copying production client configuration into a local test setup.

Related errors

AI-assisted analysis of tursodatabase/turso@bad083fafb (2026-08-16). Data as JSON: /api/errors/af01033f4ec01e03. Report an issue: GitHub.