tikv/tikv · error

streaming request is not supported for this handler

Error message

streaming request is not supported for this handler

What it means

The `RequestHandler` trait's default `handle_streaming_request` in src/coprocessor/mod.rs:170 panics for the mirror reason of error 357: it is a default only for unary handlers. Calling the streaming entry point on a handler that only overrides `handle_request` reaches this panic.

Source

Thrown at src/coprocessor/mod.rs:170

                    partial_response: Box::new(response),
                }),
            },
        }
    }
}

/// An interface for all kind of Coprocessor request handlers.
#[async_trait]
pub trait RequestHandler: Send {
    /// Processes current request and produces either a ready response or a
    /// result kept unserialized for merging.
    async fn handle_request(&mut self) -> Result<HandlerOutput> {
        panic!("unary request is not supported for this handler");
    }

    /// Processes current request and produces streaming responses.
    async fn handle_streaming_request(&mut self) -> HandlerStreamStepResult {
        panic!("streaming request is not supported for this handler");
    }

    /// Collects scan statistics generated in this request handler so far.
    fn collect_scan_statistics(&mut self, _dest: &mut Statistics) {
        // Do nothing by default
    }

    /// Collects scan executor time in this request handler so far.
    fn collect_scan_summary(&mut self, _dest: &mut ExecSummary) {
        // Do nothing by default
    }

    fn into_boxed(self) -> Box<dyn RequestHandler>
    where
        Self: 'static + Sized,
    {
        Box::new(self)
    }

View on GitHub (pinned to 78aedc1c81)

Solutions

  1. Route the request through handle_request instead of handle_streaming_request for unary handlers.
  2. If the handler should support streaming, override handle_streaming_request in your implementation.
  3. Review the coprocessor endpoint's method selection to ensure request kind matches handler capability.

Example fix

// before
let step = handler.handle_streaming_request().await; // unary-only handler panics
// after
let output = handler.handle_request().await; // dispatch unary handlers via handle_request
Defensive patterns

Strategy: type-guard

Validate before calling

// Dispatch only streaming-capable handlers through handle_streaming_request
if !handler.supports_streaming() {
    return dispatch_unary(handler);
}

Type guard

fn supports_streaming<H: RequestHandler>(_: &H) -> bool {
    H::SUPPORTS_STREAMING
}

Prevention

When it happens

Trigger: Dispatching a streaming coprocessor request to a unary-only handler — the dispatcher calls handle_streaming_request on a handler that never overrides it.

Common situations: Sending a streaming-style request type (e.g. via the streaming gRPC path) for a handler that only supports unary; new handler implementations missing the streaming override; endpoint routing mistakes.

Related errors


AI-assisted analysis of tikv/tikv@78aedc1c81 (2026-09-03). Data as JSON: /api/errors/608e5a628d176ea6. Report an issue: GitHub.