influxdata/influxdb · error · Error

queries not supported in compactor only mode

Error message

queries not supported in compactor only mode

What it means

The CompactorOnly variant is a fieldless error indicating queries were attempted against a server/component configured to run in compactor-only mode. In that mode the write buffer/query machinery is not initialized, so the query path is intentionally unsupported. It is a configuration-mismatch signal, not a data or I/O failure.

Solutions

1. Send queries to a node running in full or querier mode, not the compactor-only node
2. Change the node's configuration to enable query support if it should serve queries
3. Fix client connection strings/DNS so read traffic reaches query-capable instances
4. Check startup flags/config for the compactor-only setting and remove it if unintended

Example fix

// before
influxdb3 serve --compactor-only  # then querying this node
// after
influxdb3 serve  # full mode (or target a querier node for queries)

// before sending queries, verify the node supports them
if node_mode == NodeMode::CompactorOnly {
    return Err("this node does not serve queries; use a querier/full node");
}

fn supports_queries(mode: NodeMode) -> bool {
    !matches!(mode, NodeMode::CompactorOnly)
}

match client.query(sql).await {
    Err(e) if e.to_string().contains("compactor only mode") => {
        // fail over to a query-capable endpoint
        query_via_querier(sql).await
    }
    r => r,
}

When it happens

Trigger: Executing a query through a handle created for a compactor-only deployment (e.g. server started with a compactor-only flag/role) where the query interface is rejected unconditionally.

Common situations: Pointing a client/SDK at a compactor-only node instead of a full server or querier node; misconfiguring deployment roles in a split topology; running one binary with the wrong mode flag.

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

• An unexpected error occurred in the client library
• Cannot parse object store config
• Cannot query: (query: )
• failed to initialize write buffer
• ghost queue is NOT empty

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/a97b7f3c206a2070. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_write/src/lib.rs:57

use iox_time::Time;
use observability_deps::tracing::debug;
use schema::TIME_COLUMN_NAME;
use serde::{Deserialize, Serialize};
use std::{fmt::Debug, sync::Arc};
use thiserror::Error;

#[derive(Debug, Error)]
pub enum Error {
    #[error("object store path error: {0}")]
    ObjStorePath(#[from] object_store::path::Error),

    #[error("write buffer error: {0}")]
    WriteBuffer(#[from] write_buffer::Error),

    #[error("persister error: {0}")]
    Persister(#[from] persister::PersisterError),

    #[error("queries not supported in compactor only mode")]
    CompactorOnly,

    #[error("unexpected: {0:?}")]
    Anyhow(#[from] anyhow::Error),
}

pub type Result<T, E = Error> = std::result::Result<T, E>;

pub trait WriteBuffer: Bufferer + ChunkContainer + DistinctCacheManager + LastCacheManager {}

/// The buffer is for buffering data in memory and in the wal before it is persisted as parquet files in storage.
#[async_trait]
pub trait Bufferer: Debug + Send + Sync + 'static {
    /// Validates the line protocol, writes it into the WAL if configured, writes it into the in memory buffer
    /// and returns the result with any lines that had errors and summary statistics.
    async fn write_lp(
        &self,
        database: DatabaseName,

View on GitHub (pinned to 06200ef96b)