apache/cassandra · warning

Ran out of time. Returning best effort.

Error message

Ran out of time. Returning best effort.

What it means

When a virtual table query runs against a soft deadline and the time budget is exhausted, AbstractLazyVirtualTable either throws ReadTimeoutException (if no partial rows were collected or best-effort is off) or, in best-effort mode with partial results, emits the client warning 'Ran out of time. Returning best effort.' and returns the partial data set. It exists so slow virtual tables do not stall coordinator threads indefinitely.

Solutions

  1. Add a LIMIT clause or narrower WHERE filter to reduce how much of the virtual table is scanned.
  2. Re-run the query; retry after the node is less loaded so the deadline is met.
  3. Raise the relevant timeout configuration (e.g. read/request timeouts) if virtual table queries legitimately need more time.
  4. Treat the returned rows as incomplete; check ClientWarn warnings in your driver before relying on the result.

Example fix

// before: full scan, may return partial data
SELECT * FROM system_views.recent_messages;

// after: bounded query completes within the deadline
SELECT * FROM system_views.recent_messages LIMIT 100;
Defensive patterns

Strategy: fallback

Validate before calling

// check for the partial-result warning after querying a virtual table
Row row = session.execute("SELECT * FROM system_views.some_table LIMIT 100").getExecutionInfo().getWarnings()
    .stream().filter(w -> w.contains("Ran out of time")).findFirst().orElse(null);
if (row != null) { /* treat result as incomplete */ }

Prevention

When it happens

Trigger: SELECT from a lazy virtual table (e.g. system_views sessions/logs-style tables) whose producer takes longer than the configured deadline while OnTimeout.BEST_EFFORT is set and the collector already has rows; a correlated throw of InternalTimeoutException from a per-row/remote fetch lands in this catch block.

Common situations: Querying large virtual tables on busy nodes; slow remote-node collectors feeding a virtual table; users paging through virtual tables with no LIMIT; tight virtual-table timeouts on loaded clusters.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/cb297c3b77d402c1. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/db/virtual/AbstractLazyVirtualTable.java:766

    public UnfilteredPartitionIterator select(DecoratedKey partitionKey, ClusteringIndexFilter clusteringIndexFilter, ColumnFilter columnFilter, RowFilter rowFilter, DataLimits limits)
    {
        return select(new DataRange(new Bounds<>(partitionKey, partitionKey), clusteringIndexFilter), columnFilter, rowFilter, limits);
    }

    @Override
    public final UnfilteredPartitionIterator select(DataRange dataRange, ColumnFilter columnFilter, RowFilter rowFilter, DataLimits limits)
    {
        PartitionsCollector collector = collector(dataRange, columnFilter, rowFilter, limits);
        try
        {
            collect(collector);
        }
        catch (InternalDoneException ignore) {}
        catch (InternalTimeoutException ignore)
        {
            if (onTimeout != OnTimeout.BEST_EFFORT || collector.isEmpty())
                throw new ReadTimeoutException(ONE, 0, 1, false);
            ClientWarn.instance.warn("Ran out of time. Returning best effort.");
        }
        return collector.finish();
    }

    @Override
    public void apply(PartitionUpdate update)
    {
        throw new InvalidRequestException("Modification is not supported by table " + metadata);
    }

    @Override
    public void truncate()
    {
        throw new InvalidRequestException("Truncation is not supported by table " + metadata);
    }

    @Override
    public String toString()

View on GitHub (pinned to 88fd0f6a0e)