conductor-oss/conductor · warning · UnsupportedOperationException

secrets are disabled

Error message

secrets are disabled

What it means

Thrown by NoopSecretsDAO.putSecret when secrets functionality is entirely disabled (conductor.secrets.type=noop). The noop DAO returns null/empty for all reads and throws UnsupportedOperationException for all write operations. This means the secrets subsystem is intentionally turned off — no secrets can be stored, retrieved, or managed.

Source

Thrown at core/src/main/java/com/netflix/conductor/core/secrets/NoopSecretsDAO.java:44

    @Override
    public String getSecret(String name) {
        return null;
    }

    @Override
    public boolean secretExists(String name) {
        return false;
    }

    @Override
    public List<String> listSecretNames() {
        return Collections.emptyList();
    }

    @Override
    public void putSecret(String name, String value) {
        throw new UnsupportedOperationException("secrets are disabled");
    }

    @Override
    public void deleteSecret(String name) {
        throw new UnsupportedOperationException("secrets are disabled");
    }

    @Override
    public List<CredentialMeta> listWithMeta() {
        return List.of();
    }
}

View on GitHub (pinned to cf7c3e4a8a)

Solutions

1. Change conductor.secrets.type from 'noop' to a functional backend ('env' for read-only env vars, or a writable backend like 'database').
2. Remove or disable the code path that attempts to write secrets if secrets are intentionally not used in this deployment.
3. If using noop for testing, mock or stub the secrets-writing code path in test configuration.

Example fix

# before — secrets disabled
# application.properties
conductor.secrets.type=noop

# after — enable env-backed secrets (default)
conductor.secrets.type=env
# or use a database-backed implementation for full read/write support

// Check secrets backend type before attempting write
if (secretsDAO instanceof NoopSecretsDAO) {
    throw new IllegalStateException(
        "Secrets are disabled (conductor.secrets.type=noop). "
            + "Set conductor.secrets.type=env or a writable backend.");
}
secretsDAO.putSecret(name, value);

public boolean isSecretsEnabled(SecretsDAO dao) {
    return !(dao instanceof NoopSecretsDAO);
}

try {
    secretsDAO.putSecret(name, value);
} catch (UnsupportedOperationException e) {
    if ("secrets are disabled".equals(e.getMessage())) {
        throw new IllegalStateException(
            "Secrets subsystem is disabled. Enable it via conductor.secrets.type.", e);
    }
    throw e;
}

When it happens

Trigger: Calling the secrets API endpoint (POST /api/secrets/{name}) or any code path that invokes SecretsDAO.putSecret while 'conductor.secrets.type' is explicitly set to 'noop'. This is an opt-in configuration — the default is 'env', not 'noop'.

Common situations: A deployment explicitly disables secrets for testing or minimal-footprint environments by setting conductor.secrets.type=noop, but an application component or workflow still tries to write a secret. Misconfiguration where noop was intended for dev but leaked into a staging/prod profile.

Related errors

• environment variables are disabled
• Pinecone API key is not configured. Please set conductor.vec
• env-backed secrets are read-only
• Skill registry is not available
• llmProvider not specified: {name}

AI-assisted analysis of conductor-oss/conductor@cf7c3e4a8a (2026-08-14). Data as JSON: /api/errors/b4793a4ced766487. Report an issue: GitHub.