prestodb/presto · info · PrestoException

GENERIC_INTERNAL_ERROR

GENERIC_INTERNAL_ERROR

Error message

RecordCursor was interrupted

What it means

HiveBucketAdapterRecordCursor.advanceNextPosition checks Thread.interrupted() before delegating to the underlying cursor so a destroyed/cancelled query stops promptly. If the thread is interrupted it re-sets the interrupt flag and throws GENERIC_INTERNAL_ERROR "RecordCursor was interrupted" — this is the expected consequence of query cancellation, not a data problem.

Source

Thrown at presto-hive/src/main/java/com/facebook/presto/hive/HiveBucketAdapterRecordCursor.java:94

    public long getCompletedBytes()
    {
        return delegate.getCompletedBytes();
    }

    @Override
    public Type getType(int field)
    {
        return delegate.getType(field);
    }

    @Override
    public boolean advanceNextPosition()
    {
        while (true) {
            if (Thread.interrupted()) {
                // Stop processing if the query has been destroyed.
                Thread.currentThread().interrupt();
                throw new PrestoException(GENERIC_INTERNAL_ERROR, "RecordCursor was interrupted");
            }

            boolean hasNextPosition = delegate.advanceNextPosition();
            if (!hasNextPosition) {
                return false;
            }
            for (int i = 0; i < scratch.length; i++) {
                int index = bucketColumnIndices[i];
                if (delegate.isNull(index)) {
                    scratch[i] = null;
                    continue;
                }
                Class<?> javaType = javaTypeList.get(i);
                if (javaType == boolean.class) {
                    scratch[i] = delegate.getBoolean(index);
                }
                else if (javaType == long.class) {
                    scratch[i] = delegate.getLong(index);

View on GitHub (pinned to 55bb57d202)

Solutions

1. No fix needed if the query was intentionally cancelled; treat it as expected cancellation noise.
2. If unexpected, check the coordinator logs for what destroyed the query (memory limit, kill command, failure in another stage).
3. Reduce memory pressure or increase limits (query.max-memory, memory.max-per-node) if queries are being killed automatically.
4. Retry the query if it was killed transiently by an external system.

try {
    while (cursor.advanceNextPosition()) { /* consume */ }
} catch (PrestoException e) {
    if ("RecordCursor was interrupted".equals(e.getMessage())) {
        // query was cancelled/destroyed; stop processing, no retry
        return;
    }
    throw e;
}

When it happens

Trigger: The driver thread iterating the cursor is interrupted — query killed via UI/CLI, cancellation due to memory/limit/excess spill policy, session timeout — while advanceNextPosition is blocked reading the next row.

Common situations: Long-running Hive scans cancelled by a user or by query max-run-time; queries destroyed by the scheduler for low memory or failure of another stage; noisy-neighbor cluster kills. Seeing this in logs alongside a 'Query was canceled' is normal.

Related errors

• Expected field to be %s, actual %s (field %s)
• HIVE_FILESYSTEM_ERROR
• INVALID_ANALYZE_PROPERTY
• unknown java type
• HIVE_INVALID_BUCKET_FILES

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/374f047afd622b3e. Report an issue: GitHub.