apache/druid · warning

Failed to deserialize authorizer role, ignoring: %s

Error message

Failed to deserialize authorizer role, ignoring: %s

What it means

BasicAuthorizerRole's permission deserializer parses each permission node in a role individually; if one node cannot be converted to a BasicAuthorizerPermission (JsonProcessingException), it logs this warning with the node's pretty-printed JSON and skips it instead of failing the whole role. Unknown/newer permission resource types are deliberately ignored for cross-version compatibility.

Source

Thrown at extensions-core/druid-basic-security/src/main/java/org/apache/druid/security/basic/authorization/entity/BasicAuthorizerRole.java:117

        JsonParser jsonParser,
        DeserializationContext deserializationContext
    ) throws IOException
    {
      List<BasicAuthorizerPermission> permissions = new ArrayList<>();
      // sanity check
      ObjectCodec codec = jsonParser.getCodec();
      JsonNode hopefullyAnArray = codec.readTree(jsonParser);
      if (!hopefullyAnArray.isArray()) {
        throw new RE("Failed to deserialize authorizer role list");
      }

      for (JsonNode node : hopefullyAnArray) {
        try {
          permissions.add(codec.treeToValue(node, BasicAuthorizerPermission.class));
        }
        catch (JsonProcessingException e) {
          // ignore unparseable, it might be resource types we don't know about
          log.warn(e, "Failed to deserialize authorizer role, ignoring: %s", node.toPrettyString());
        }
      }

      return permissions;
    }
  }
}

View on GitHub (pinned to 9b90983fd2)

Solutions

1. Inspect the logged pretty-printed node to see which permission is malformed and fix or remove it in the metadata store
2. Recreate the role through the API so permissions conform to BasicAuthorizerPermission schema
3. Align Druid versions across the cluster if roles come from a newer version
4. Back up and clean authorizer tables in the metadata store if corruption is widespread
5. If the dropped permission is intentional/unknown, the warning is safe to ignore

Example fix

// before: hand-edited permission with unknown resourceType
{"resourceName":"x","action":"READ","type":"MysteryType"}
// after: valid permission
{"resource":{"name":"x","type":"DATASOURCE"},"action":"READ"}

// validate permission nodes against the schema before persisting roles
for (JsonNode node : permissionsArray) {
  mapper.treeToValue(node, BasicAuthorizerPermission.class); // throws if invalid
}

try {
  role = mapper.readValue(bytes, BasicAuthorizerRole.class);
} catch (JsonProcessingException e) {
  log.warn(e, "role contains unparseable permissions; they will be skipped");
}

When it happens

Trigger: Loading authorizer role metadata whose permissions array contains an entry that does not match BasicAuthorizerPermission's schema (unknown resourceType/action values, malformed fields).

Common situations: Roles edited by hand in metadata storage; roles created by a newer Druid version being read by an older one; corrupted or partially-updated metadata store rows; migration scripts writing incompatible permission JSON.

Understand the failure class

Background: "failed to unmarshal" / json.Unmarshal errors: why parsing a response into a Go struct fails and how to fix it — this error's family across 23 libraries.

Related errors

• unknown event type [%s]
• interrupted flushing elements from queue
• Cannot deserialize type[%s] to an RoaringBitmap64Counter:
• Failed to deserialize to RoaringBitmap64Counter, input is an
• Object cannot be deserialized to a Moments Sketch:

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/4ff4962fb1fe2a65. Report an issue: GitHub.