risingwavelabs/risingwave · error · ConnectorError

Unsupported split type for adaptive splits

Error message

Unsupported split type for adaptive splits: {:?}

What it means

fill_adaptive_split redistributes splits across actors for sources that support adaptive split assignment (currently only Google Pub/Sub style split templates). Any other SplitImpl variant falls into the catch-all arm and returns this error, because adaptive rescaling cannot interpret that split type.

Solutions

  1. Only call fill_adaptive_split for sources whose SplitImpl supports adaptive splits (e.g. GooglePubsub)
  2. Route other connectors through their normal static split assignment path
  3. Add a match arm implementing adaptive splitting if the new connector supports it

Example fix

// before
fill_adaptive_split(&split_template, &fragment_id, &actor_ids)?; // split_template is a Kafka split
// after
if split_template.is_adaptive_supported() { fill_adaptive_split(...) } else { assign_static_splits(...) }
Defensive patterns

Strategy: type-guard

Validate before calling

const adaptiveSplitSources = ['GooglePubsub'];
function supportsAdaptiveSplits(splitType) { return adaptiveSplitSources.includes(splitType); }

Type guard

const isAdaptiveSplit = (s) => s.type === 'GooglePubsub' || s.type === 'Pubsub';

Try / catch

match fill_adaptive_split(tpl, fid, actors) { Err(e) if String(e).contains("Unsupported split type") => assign_static_splits(tpl, actors), r => r }

Prevention

When it happens

Trigger: Calling fill_adaptive_split (directly or via resolve_fragment_to_actor_splits/reassign_splits) with a split template from a connector without adaptive-split support, e.g. Kafka, Kinesis, or NATS splits passed to the adaptive path.

Common situations: Fragment/actor rescaling code wired to a source whose SplitImpl variant is not the adaptive-supported one; adding a new connector and forgetting to either support or exclude it from adaptive splitting; unit tests like test_fill_adaptive_split_unsupported exercising the error path.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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

Appendix: source

Thrown at src/connector/src/source/util.rs:67

            for idx in 0..actor_count {
                let split_id: Arc<str> = format!("{}-{}", split.subscription, idx).into();
                new_splits.insert(
                    split_id,
                    SplitImpl::GooglePubsub(PubsubSplit {
                        index: idx as u32,
                        subscription: split.subscription.clone(),
                        __deprecated_start_offset: None,
                        __deprecated_stop_offset: None,
                    }),
                );
            }
            tracing::debug!(
                "Filled adaptive splits for GooglePubsub source, {} splits in total",
                new_splits.len()
            );
            Ok(new_splits)
        }
        _ => Err(ConnectorError::from(anyhow::anyhow!(
            "Unsupported split type for adaptive splits: {:?}",
            split_template
        ))),
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    use crate::source::SplitMetaData;
    use crate::source::nats::split::NatsOffset;

    #[test]
    fn test_fill_adaptive_split_pubsub() {
        let template = SplitImpl::GooglePubsub(PubsubSplit {
            index: 0,
            subscription: "projects/p/subscriptions/s".to_owned(),
            __deprecated_start_offset: None,

View on GitHub (pinned to 6469eb736d)