What causes "Failed to execute [%s]: %s" in openzipkin/zipkin?

Read the wrapped CQL statement and server message in the error to identify the failing line.

openzipkin/zipkin · critical · RuntimeException

Failed to execute [%s]: %s

Error message

Failed to execute [%s]: %s

What it means

Thrown while applying a schema cql file when session.execute(cmd) raises InvalidQueryException. The error wraps the exact CQL statement and the server's message so it is obvious which line of the resource failed. It is logged at ERROR before rethrowing so it appears in server logs, not only in API responses.

Source

Thrown at zipkin-storage/cassandra/src/main/java/zipkin2/storage/cassandra/Schema.java:201

  static boolean hasUpgrade2_remoteService(KeyspaceMetadata keyspaceMetadata) {
    return keyspaceMetadata.getTable(TABLE_SERVICE_REMOTE_SERVICES).isPresent();
  }

  static void applyCqlFile(Version version, String keyspace, CqlSession session, String resource) {
    for (String cmd : resourceToString(resource).split(";", 100)) {
      cmd = cmd.trim().replace(" " + DEFAULT_KEYSPACE, " " + keyspace);
      if (cmd.isEmpty()) continue;
      cmd = reviseCQL(version, cmd);
      try {
        session.execute(cmd);
      } catch (InvalidQueryException e) {
        // Add context so it is obvious which line was wrong
        String message = "Failed to execute [%s]: %s".formatted(cmd, e.getMessage());
        // Ensure we can look at logs to see the problem. Otherwise, it may only
        // be visible in API error responses, such as /health or /api/v2/traces.
        LOG.error(message);
        throw new RuntimeException(message, e);
      }
    }
  }

  static String reviseCQL(Version version, String cql) {
    if (version.getMajor() >= 4) {
      // read_repair_chance options were removed and make Cassandra crash starting in v4
      // See https://cassandra.apache.org/doc/latest/operating/read_repair.html#background-read-repair
      cql = cql.replaceAll(" *AND [^\\s]*read_repair_chance = 0\n", "");
    }
    return cql;
  }

  Schema() {
  }
}

View on GitHub (pinned to 878ce2a1fa)

Solutions

Read the wrapped CQL statement and server message in the error to identify the failing line.
Verify the Cassandra user has CREATE TABLE / INDEX / TYPE privileges on the keyspace.
Confirm the Cassandra version is supported (>= 3.11.3) and matches the schema expectations; if a partial schema exists, drop the keyspace and retry a clean install.

Defensive patterns

Strategy: try-catch

Try / catch

catch (RuntimeException e) { log.error("Schema apply failed at statement: {}", e.getMessage(), e); if (e.getCause() instanceof InvalidQueryException iqe && iqe.getMessage().contains("Permission")) escalateToDba(); }

Prevention

Pre-verify the Cassandra user can CREATE in the target keyspace before enabling ensureSchema.
Match the schema cql version to your Cassandra major version.

When it happens

Trigger: Running Schema.ensure/applyCqlFile with ensureSchema=true against a Cassandra version whose syntax differs (e.g. read_repair_chance on Cassandra 4 handled by reviseCQL, other drift on other versions), insufficient permissions to create tables, or a keyspace name substitution mismatch.

Common situations: Schema install against a newer/older Cassandra than supported; a restricted Cassandra user without CREATE privileges; partially-applied schema from a previous failed attempt.

Related errors

AI-assisted analysis of openzipkin/zipkin@878ce2a1fa (2026-08-14). Data as JSON: /api/errors/72ce5868ad3e2b49. Report an issue: GitHub.