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
- Route the request through handle_request instead of handle_streaming_request for unary handlers.
- If the handler should support streaming, override handle_streaming_request in your implementation.
- 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
- Override handle_streaming_request in any handler that supports streaming.
- Route requests by request kind (unary vs streaming) at the endpoint layer.
- Document per-handler capabilities to prevent misrouting during refactors.
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
- unary request is not supported for this handler
- Unknown analyze version: {}
- not implemented
- cannot resolve the conflict {} for key {}
- must_cached call but the future not ready
AI-assisted analysis of tikv/tikv@78aedc1c81 (2026-09-03).
Data as JSON: /api/errors/608e5a628d176ea6.
Report an issue: GitHub.