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,
typeView on GitHub (pinned to 9b90983fd2)
Solutions
- Query only datasources the user has READ access to, or grant READ on the requested datasource.
- Remove the dataSource filter to list only authorized tasks (results are permission-filtered anyway).
- 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
- Query only datasources the caller has READ access to; otherwise omit filters.
- Inspect the Access-Check-Result body to map the denial to a specific resource/action.
- Keep listing credentials and datasource grants in sync.
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
- authResult.getErrorMessage()
- Access-Check-Result: %s
- User [%s] does not have role [%s].
- Group mapping [%s] already has role [%s].
- Group mapping [%s] does not have role [%s].
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/d652d26bd0c97f35.
Report an issue: GitHub.