apache/druid · error · WebApplicationException

Access-Check-Result: %s

Error message

Access-Check-Result: %s

What it means

The task-listing endpoint (getTasks, backing waiting/pending/running/complete views) filters tasks by the caller's datasource permissions. When the authorization check fails, it returns HTTP 403 with a plain-text body containing 'Access-Check-Result: <message>'.

Source

Thrown at indexing-service/src/main/java/org/apache/druid/indexing/overlord/http/OverlordResource.java:617

                       .entity(errorMessage)
                       .build();
      }
    }
    // early authorization check if datasource != null
    // fail fast if user not authorized to access datasource
    if (dataSource != null) {
      final ResourceAction resourceAction = new ResourceAction(
          new Resource(dataSource, ResourceType.DATASOURCE),
          Action.READ
      );
      final AuthorizationResult authResult = AuthorizationUtils.authorizeResourceAction(
          req,
          resourceAction,
          authorizerMapper
      );

      if (!authResult.allowAccessWithNoRestriction()) {
        throw new WebApplicationException(
            Response.status(Response.Status.FORBIDDEN)
                    .type(MediaType.TEXT_PLAIN)
                    .entity(StringUtils.format("Access-Check-Result: %s", authResult.getErrorMessage()))
                    .build()
        );
      }
    }

    return asLeaderWith(
        taskMaster.getTaskRunner(),
        taskRunner -> {
          final List<TaskStatusPlus> authorizedList = securedTaskStatusPlus(
              taskQueryTool.getTaskStatusPlusList(
                  TaskStateLookup.fromString(state),
                  dataSource,
                  createdTimeInterval,
                  maxCompletedTasks,
                  type

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Query only datasources the user has READ access to, or grant READ on the requested datasource.
  2. Remove the dataSource filter to list only authorized tasks (results are permission-filtered anyway).
  3. Read the Access-Check-Result body to identify the denied resource/action and fix the role.
Defensive patterns

Strategy: try-catch

Try / catch

Response r = target("/druid/indexer/v1/tasks").request().get();
if (r.getStatus() == 403) {
  String body = r.readEntity(String.class); // Access-Check-Result: ...
  // narrow the dataSource filter or grant READ
}

Prevention

When it happens

Trigger: GET /druid/indexer/v1/tasks (or /waiting, /pending, /running, /complete) with a dataSource/type filter the caller cannot READ, so the resource action check denies the request.

Common situations: Users listing tasks for datasources outside their role; API scripts using service tokens without READ on the queried datasource; a wrong datasource name mapping to an unauthorized resource.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


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