influxdata/influxdb · critical
Azure blob storage support not enabled, recompile with the…
Error message
Azure blob storage support not enabled, recompile with the azure feature enabled
What it means
This panic is raised by influxdb3_clap_blocks when an Azure Blob Storage object store is requested but the crate was compiled without the 'azure' cargo feature. The `new_azure` constructor is compiled only as a stub under `#[cfg(not(feature = "azure"))]` and deliberately panics on any call, since Azure support code does not exist in the binary.
Solutions
- Rebuild the binary with the azure feature: `cargo build --features azure` (or the crate's documented azure feature combination).
- Use a release artifact that was built with azure support enabled.
- Switch the object store configuration to a supported backend (e.g. s3, gcs, file) that is enabled in the current build.
- Add a startup config check that rejects azure object store config before the factory panics.
Example fix
// before (build command) cargo build --release // after cargo build --release --features influxdb3_clap_blocks/azure
Defensive patterns
Strategy: fallback
Validate before calling
// compile-time guard: only reference azure when the feature exists
#[cfg(feature = "azure")]
fn use_azure(cfg: &ObjectStoreConfig) { /* build azure store */ }
#[cfg(not(feature = "azure"))]
fn use_azure(_cfg: &ObjectStoreConfig) -> Result<(), String> {
Err("azure support not compiled in; use s3/gcs/file".into())
} Type guard
fn azure_supported() -> bool { cfg!(feature = "azure") } Prevention
- Match build features to deployment object store backend (CI matrix for azure builds).
- Validate object store config against compiled features at startup before constructing stores.
- Use a supported backend in default images.
When it happens
Trigger: Starting InfluxDB 3 with `--object-store azure` (or equivalent azure blob config) against a binary built without `--features azure`. The panic fires when the object store factory tries to construct the Azure-backed LimitObjectStore.
Common situations: Deploying a default `cargo build` / prebuilt release binary that lacks the azure feature, then pointing object store config at Azure; CI builds azure-related configs without enabling the feature; upgrading and forgetting that azure is an opt-in compile-time feature.
Related errors
- GCS support not enabled, recompile with the gcp feature…
- S3 support not enabled, recompile with the aws feature…
- valid object store URL
- another process has written to the WAL ahead of this one
- at least one expr
AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19).
Data as JSON: /api/errors/e04bd30af7ed3d73.
Report an issue: GitHub.
Appendix: source
Thrown at influxdb3_clap_blocks/src/object_store.rs:1003
builder = builder.with_allow_http(self.azure_allow_http);
if let Some(endpoint) = &self.azure_endpoint {
builder = builder.with_endpoint(endpoint.to_string());
}
Ok(object_store_limit::LimitObjectStore::new(
Arc::new(builder.build().context(InvalidAzureConfigSnafu)?),
self.object_store_connection_limit.get(),
semaphore_metrics,
))
}
#[cfg(not(feature = "azure"))]
fn new_azure(
&self,
_semaphore_metrics: &Arc<tracker::AsyncSemaphoreMetrics>,
) -> Result<object_store_limit::LimitObjectStore, ParseError> {
panic!("Azure blob storage support not enabled, recompile with the azure feature enabled")
}
/// Create config-dependant object store.
///
/// Semaphore metrics are not registered with any metric registry.
/// Use [`Self::make_object_store_with_metrics`] to register them.
pub fn make_object_store(&self) -> Result<Arc<DynObjectStore>, ParseError> {
let metrics = Arc::new(tracker::AsyncSemaphoreMetrics::new_unregistered());
self.make_object_store_inner(&metrics)
}
/// Create the object store with semaphore metrics registered in the
/// provided [`metric::Registry`] under the `"object_store_limit"`
/// semaphore attribute.
pub fn make_object_store_with_metrics(
&self,
registry: &metric::Registry,
) -> Result<Arc<DynObjectStore>, ParseError> {View on GitHub (pinned to 06200ef96b)