risingwavelabs/risingwave · critical

{} remote object store only supports s3, minio, gcs, oss, co

Error message

{} remote object store only supports s3, minio, gcs, oss, cos, azure blob, hdfs, disk, memory.

What it means

build_remote_object_store calls unimplemented!() when given a remote store URL whose scheme is not among the supported ones (s3, minio, gcs, oss, cos, azblob/azure blob, hdfs, disk, memory, sim under madsim). This aborts the process with the listed supported schemes.

Source

Thrown at src/object_store/src/object/mod.rs:1054

                );
            } else {
                tracing::warn!(
                    "You're using in-memory remote object store for {}. This should never be used in benchmarks and production environment.",
                    ident
                );
            }
            ObjectStoreImpl::InMem(InMemObjectStore::shared().monitored(metrics, config))
        }
        #[cfg(debug_assertions)]
        "memory-isolated-for-test" /* isolated memory is only available for tests */ => {
            ObjectStoreImpl::InMem(InMemObjectStore::for_test().monitored(metrics, config))
        }
        #[cfg(madsim)]
        sim if sim.starts_with("sim://") => {
            ObjectStoreImpl::Sim(SimObjectStore::new(url).monitored(metrics, config))
        }
        other => {
            unimplemented!(
                "{} remote object store only supports s3, minio, gcs, oss, cos, azure blob, hdfs, disk, memory.",
                other
            )
        }
    }
}

#[inline(always)]
fn get_retry_strategy(
    config: &ObjectStoreConfig,
    operation_type: OperationType,
) -> impl Iterator<Item = Duration> + use<> {
    let attempts = get_retry_attempts_by_type(config, operation_type);
    exponential_backoff(
        Duration::from_millis(config.retry.req_backoff_interval_ms),
        config.retry.req_backoff_factor,
        Duration::from_millis(config.retry.req_backoff_max_delay_ms),
    )

View on GitHub (pinned to 6469eb736d)

Solutions

1. Fix the URL prefix to one of: s3://, minio://, gcs://, oss://, cos://, azblob://, hdfs://, disk://, memory://
2. Check the config file for truncation or corruption of the store URL
3. If migrating from an old scheme (e.g. s3-compatible://), see the s3 unification note and use s3:// instead

Example fix

// before
let store = build_remote_object_store("s3a://my-bucket/data", metrics, config)?;
// after
let store = build_remote_object_store("s3://my-bucket/data", metrics, config)?;

// Check the URL scheme against the supported list before calling build_remote_object_store
const SUPPORTED: [&str; 9] = ["s3://","minio://","gcs://","oss://","cos://","azblob://","hdfs://","disk://","memory://"];
if !url.is_empty() && !SUPPORTED.iter().any(|p| url.starts_with(p)) {
    return Err(format!("unsupported remote store URL: {}", url));
}

fn has_supported_scheme(url: &str) -> bool {
    ["s3://","minio://","gcs://","oss://","cos://","azblob://","hdfs://","disk://","memory://"]
        .iter().any(|p| url.starts_with(p)) || url.is_empty()
}

When it happens

Trigger: Any caller (get_object_store, create_sstable_store, etc.) receiving a URL with an unrecognized prefix — e.g. a typo like s3a://, fs://, or a scheme removed in a newer version.

Common situations: Typo in the state store URL in config, using a scheme from another system, or a removed/renamed scheme after an upgrade.

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

• invalid listen address
• sql endpoint is required
• Passing s3-compatible is not supported, please modify the en
• total_memory_bytes {} is larger than the total memory availa
• parallelism should not be zero

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