risingwavelabs/risingwave · error · SinkError::DorisStarrocksConnect
Insert error
Error message
Insert error: {}, {}, {:?} What it means
The stream-load response was valid JSON but its `status` is not in `STARROCKS_SUCCESS_STATUS` (e.g. not "Success"/"Publish Timeout"), so the insert failed on the StarRocks side and the status, message, and error_url are surfaced in the error.
Solutions
- Fetch the error_url from the message in a browser/curl to see the exact row-level load errors
- Align the RisingWave sink schema with the StarRocks table columns (names, order, types)
- Fix incompatible data values (e.g. oversized strings, NULLs in NOT NULL columns, bad date formats)
- Check StarRocks BE logs and cluster health if errors are resource-related
Example fix
// before (StarRocks) CREATE TABLE t (id INT, ts DATETIME NOT NULL) PRIMARY KEY(id)...; // after: make source supply ts or make column nullable CREATE TABLE t (id INT, ts DATETIME NULL) PRIMARY KEY(id)...;
Defensive patterns
Strategy: try-catch
Validate before calling
// Confirm schema compatibility before sinking: SELECT column_name, column_type, is_nullable FROM information_schema.columns WHERE table_schema='db' AND table_name='t';
Try / catch
match err {
SinkError::DorisStarrocksConnect(e) if format!("{}", e).starts_with("Insert error") => {
// parse error_url from message and inspect detailed row errors
}
other => handle(other),
} Prevention
- Keep RisingWave sink schema and StarRocks table schema in sync
- Always inspect the error_url in the message for row-level details
- Avoid NULLs for NOT NULL columns; validate data formats (dates, numbers)
When it happens
Trigger: Batch stream-load insert rejected: schema mismatch (column count/types), data type conversion failure, wrong label/duplicate, BE overload, or any load-time error reported by StarRocks with a non-success status.
Common situations: RisingWave schema drifted from the StarRocks table (added/dropped/reordered columns); inserting a value that can't be cast to the StarRocks column type; NULL into a non-nullable column. The `error_url` in the message points to detailed per-row error logs on the StarRocks BE.
Understand the failure class
Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.
Related errors
- Starrocks error
- Can't get label from response
- channel closed
- `commit_checkpoint_interval` must be greater than 0
- Doris error
AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11).
Data as JSON: /api/errors/761663e164e4b740.
Report an issue: GitHub.
Appendix: source
Thrown at src/connector/src/sink/starrocks.rs:885
insert: InserterInner,
}
impl StarrocksClient {
pub fn new(insert: InserterInner) -> Self {
Self { insert }
}
pub async fn write(&mut self, data: Bytes) -> Result<()> {
self.insert.write(data).await?;
Ok(())
}
pub async fn finish(self) -> Result<StarrocksInsertResultResponse> {
let raw = self.insert.finish().await?;
let res: StarrocksInsertResultResponse = serde_json::from_slice(&raw)
.map_err(|err| SinkError::DorisStarrocksConnect(anyhow!(err)))?;
if !STARROCKS_SUCCESS_STATUS.contains(&res.status.as_str()) {
return Err(SinkError::DorisStarrocksConnect(anyhow::anyhow!(
"Insert error: {}, {}, {:?}",
res.status,
res.message,
res.error_url,
)));
};
Ok(res)
}
}
pub struct StarrocksTxnClient {
request_builder: StarrocksTxnRequestBuilder,
}
impl StarrocksTxnClient {
pub fn new(request_builder: StarrocksTxnRequestBuilder) -> Self {
Self { request_builder }
}View on GitHub (pinned to 6469eb736d)