What causes "failed to send the start response" in risingwavelabs/risingwave?

Retry the sink start; the writer will reconnect and receive the response.

risingwavelabs/risingwave · warning · anyhow::Error

failed to send the start response

Error message

failed to send the start response

What it means

`start` sends the StartCoordinationResponse over the gRPC response channel (`response_tx`) and maps a send failure to this error. A send fails only when the receiver side has been dropped — the client stream was closed/cancelled or the connection broke. Note this is a response-channel failure, not a transport send in the network sense.

Source

Thrown at src/meta/src/manager/sink_coordination/handle.rs:75

    }

    pub(super) fn vnode_bitmap(&self) -> &Bitmap {
        &self.vnode_bitmap
    }

    pub(super) fn start(
        &mut self,
        log_store_rewind_start_epoch: Option<u64>,
    ) -> anyhow::Result<()> {
        self.response_tx
            .send(Ok(CoordinateResponse {
                msg: Some(coordinate_response::Msg::StartResponse(
                    StartCoordinationResponse {
                        log_store_rewind_start_epoch,
                    },
                )),
            }))
            .map_err(|_| anyhow!("failed to send the start response"))
    }

    pub(super) fn ack_aligned_initial_epoch(
        &mut self,
        aligned_initial_epoch: u64,
    ) -> anyhow::Result<()> {
        self.response_tx
            .send(Ok(CoordinateResponse {
                msg: Some(coordinate_response::Msg::AlignInitialEpochResponse(
                    aligned_initial_epoch,
                )),
            }))
            .map_err(|_| anyhow!("failed to send the start response"))
    }

    pub(super) fn abort(self, status: Status) {
        let _ = self.response_tx.send(Err(status));
    }

View on GitHub (pinned to 6469eb736d)

Solutions

Retry the sink start; the writer will reconnect and receive the response.
Increase the writer's RPC/stream timeout so it does not cancel while the coordinator is still initializing.
Check meta node load and logs for delays between handle registration and `start` being called.
Treat this error as benign if the writer already aborted — the coordinator should log and drop the handle.

Defensive patterns

Strategy: retry

Try / catch

// writer/client side: wrap the coordination RPC with retry
match client.start_coordination().await {
    Err(e) if e.is_stream_closed() => retry_with_backoff(),
    other => other,
}

Prevention

Set writer RPC timeouts longer than worst-case coordinator startup.
Retry the coordination session on stream closure; it is safe to reconnect.
Monitor meta node load — slow coordinator loops cause client-side cancellations.

When it happens

Trigger: The sink writer disconnects or cancels its gRPC stream between connecting and receiving the StartCoordinationResponse; the coordinator is slow to start (e.g. blocked in init/alignment) and the client times out and closes the stream.

Common situations: Writer-side RPC timeouts set too low relative to coordinator startup time; network partition or writer restart right after connection; meta node overload delaying the coordinator loop.

Related errors

AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/6de177b7238bc9de. Report an issue: GitHub.