prestodb/presto · error · PrestoException
REMOTE_TASK_MISMATCH
REMOTE_TASK_MISMATCH
Error message
%s (%s)
What it means
Presto throws REMOTE_TASK_MISMATCH when a PageBufferClient receives results from a remote task whose TaskInstanceId differs from the one previously seen for that URI. This indicates the remote stage/task was replaced or restarted (e.g. rescheduled after failure) while this client still holds state bound to the old instance. It protects against mixing data from different executions of the same logical task location.
Source
Thrown at presto-main-base/src/main/java/com/facebook/presto/operator/PageBufferClient.java:300
@Override
public void onSuccess(PagesResponse result)
{
checkNotHoldsLock(this);
backoff.success();
List<SerializedPage> pages;
boolean pagesAccepted;
try {
boolean shouldAcknowledge = false;
synchronized (PageBufferClient.this) {
if (taskInstanceId == null) {
taskInstanceId = result.getTaskInstanceId();
}
if (!isNullOrEmpty(taskInstanceId) && !result.getTaskInstanceId().equals(taskInstanceId)) {
// TODO: update error message
throw new PrestoException(REMOTE_TASK_MISMATCH, format("%s (%s)", REMOTE_TASK_MISMATCH_ERROR, fromUri(uri)));
}
if (result.getToken() == token) {
pages = result.getPages();
token = result.getNextToken();
shouldAcknowledge = pages.size() > 0;
}
else {
pages = ImmutableList.of();
}
}
if (shouldAcknowledge && acknowledgePages) {
// Acknowledge token without handling the response.
// The next request will also make sure the token is acknowledged.
// This is to fast release the pages on the buffer side.
resultClient.acknowledgeResultsAsync(result.getNextToken());
}View on GitHub (pinned to 55bb57d202)
Solutions
- Retry the query; the failed task is usually replaced and a fresh schedule will use consistent task instances.
- Check the target worker logs for task failure/eviction events at that URI to find the root cause of the task replacement.
- Upgrade Presto — the code itself notes 'TODO: update error message'; newer versions surface more context on task instance mismatches.
- Reduce memory pressure/spill pressure so tasks are not failed and rescheduled mid-query.
- If it recurs on the same host, drain and restart that worker; stale task instances may persist.
Defensive patterns
Strategy: retry
Try / catch
// JDBC / client
try {
results = statement.executeQuery();
} catch (ExecutionRemoteTaskException | PrestoException e) {
if ("REMOTE_TASK_MISMATCH".equals(e.getErrorCode().getName())) {
// retry the query; task was replaced mid-execution
results = retryWithBackoff(() -> statement.executeQuery(), 2);
} else { throw e; }
} Prevention
- Retry transient remote-task errors at the client level with backoff
- Keep worker versions/config uniform across the cluster to avoid stale task instances
- Monitor worker task failure and eviction metrics; address memory pressure that triggers rescheduling
- Restart or drain workers that repeatedly report task instance mismatches
When it happens
Trigger: A subsequent HTTP result fetch via onSuccess returns a TaskExchangeClient response whose getTaskInstanceId() differs from the taskInstanceId captured on the first response for that uri. Happens after the remote task is retried/restarted on the same node, or a stale/zombie old task keeps serving on the exchange URI.
Common situations: Cluster under memory pressure causing task failures and automatic retries; node reuse of the same port after worker restart; long-running queries whose scheduled tasks get revoked and rescheduled; query retries producing a new task instance at the same URI.
Related errors
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/1a3920a879d2b741.
Report an issue: GitHub.