risingwavelabs/risingwave · error · MetaError

Secret error

Error message

Secret error: {0}

What it means

MetaError::SecretError wraps a SecretError from the secret-management subsystem into the meta error enum (`#[from]` auto-converts). It is raised when meta-node code creates, reads, or references secrets (used by connectors/sinks for credentials) and the secret layer fails, e.g. the secret cannot be found, decoded, or produced for the cluster.

Solutions

1. Inspect the wrapped SecretError source for the exact cause
2. Recreate the secret with CREATE SECRET and update the sink/source to reference the new secret id
3. Verify the secret exists: `SHOW SECRETS` and check the referenced id
4. Check meta node logs/backtrace for the failing secret read/write path
5. Ensure the secret payload format is supported by the cluster version

Example fix

// before
let secret = meta.read_secret(id).await?; // propagates MetaError::SecretError
// after
let secret = meta.read_secret(id).await
    .map_err(|e| { tracing::error!("secret {} unavailable: {e}", id); e })?;

// Before creating a sink/source that references a secret
let exists = show_secrets(conn).await?.iter().any(|s| s.name == secret_name);
if !exists {
    return Err(format!("secret {secret_name} must be created first").into());
}

fn is_secret_error(e: &MetaError) -> Option<&SecretError> {
    match e { MetaError::SecretError(s) => Some(s), _ => None }
}

match create_result {
    Err(MetaError::SecretError(e)) => {
        tracing::error!("secret layer failed: {e:#}");
        // recreate secret, then retry the operation
    }
    other => other?,
}

When it happens

Trigger: CREATE SECRET or secret-related RPCs failing validation/encoding; a sink or source referencing a secret_id that cannot be read from the meta store; secret payload decoding failures during connector startup on the meta side.

Common situations: Secret referenced by a sink/source was dropped or never created; corrupted or unsupported secret encoding; permission/consistency issues between frontend, meta, and compute nodes regarding secret read APIs.

Related errors

• has been deprecated, please use instead.
• adhoc recovery triggered
• ALTER ICEBERG TABLE does not support SECRET or CONNECTION…
• Both `access_key` and `secret_key` must be provided
• Cannot alter the job

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

Appendix: source

Thrown at src/meta/src/error.rs:144

        #[from]
        #[backtrace]
        anyhow::Error,
    ),

    // Indicates that recovery was triggered manually.
    #[error("adhoc recovery triggered")]
    AdhocRecovery,

    #[error("Integrity check failed")]
    IntegrityCheckFailed,

    #[error("{0} has been deprecated, please use {1} instead.")]
    Deprecated(String, String),

    #[error(transparent)]
    NotImplemented(#[from] NotImplemented),

    #[error("Secret error: {0}")]
    SecretError(
        #[from]
        #[backtrace]
        SecretError,
    ),
}

impl MetaError {
    /// Provide the Postgres error code for the error.
    fn provide_postgres_error_code(&self, request: &mut std::error::Request<'_>) {
        match self.inner() {
            MetaErrorInner::CatalogIdNotFound { .. } => {
                request.provide_value(PostgresErrorCode::UndefinedObject);
            }
            MetaErrorInner::Duplicated { .. } => {
                request.provide_value(PostgresErrorCode::DuplicateObject);
            }
            _ => {}

View on GitHub (pinned to 6469eb736d)