apache/cassandra · error · InvalidRequestException

Static rows are not supported for remote table

Error message

Static rows are not supported for remote table

What it means

The underlying remote table has static columns, but the virtual table mapping cannot represent static rows (its schema folds remote clustering into partition keys). A write containing a non-empty static row is rejected with InvalidRequestException.

Source

Thrown at src/java/org/apache/cassandra/db/virtual/RemoteToLocalVirtualTable.java:554

                }

                DecoratedKey key = remoteClusteringToLocalPartitionKey(local, start, pkCount, pkBuffer);
                builder = maybeRolloverAndWait(key, builder, results, endpoint);
                if (start.size() == pkCount && end.size() == pkCount)
                {
                    builder.addPartitionDeletion(rt.deletionTime());
                }
                else
                {
                    start = ClusteringBound.create(start.kind(), Clustering.make(remoteClusteringToLocalClustering(start.clustering(), pkCount, ckBuffer)));
                    end = ClusteringBound.create(end.kind(), Clustering.make(remoteClusteringToLocalClustering(end.clustering(), pkCount, ckBuffer)));
                    builder.add(new RangeTombstone(Slice.make(start, end), rt.deletionTime()));
                }
            }
        }

        if (!update.staticRow().isEmpty())
            throw new InvalidRequestException("Static rows are not supported for remote table " + metadata);

        try (BTree.FastBuilder<ColumnData> columns = BTree.fastBuilder())
        {
            for (Row row : update)
            {
                Clustering<?> clustering = row.clustering();
                DecoratedKey key = remoteClusteringToLocalPartitionKey(local, clustering, pkCount, pkBuffer);
                builder = maybeRolloverAndWait(key, builder, results, endpoint);
                Clustering<?> newClustering = Clustering.make(remoteClusteringToLocalClustering(clustering, pkCount, ckBuffer));
                columns.reset();
                for (ColumnData cd : row)
                    columns.add(rebind(local, cd));
                builder.add(BTreeRow.create(newClustering, row.primaryKeyLivenessInfo(), row.deletion(), columns.build()));
            }
        }

        if (builder != null)
            results.add(send(Verb.VIRTUAL_MUTATION_REQ, new VirtualMutation(builder.build()), endpoint));

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Do not set static columns when writing through the virtual table; write static columns via the underlying table on the owning node.
  2. Remove static column assignments from the INSERT/UPDATE statement.
  3. Consider dropping the static column from the underlying table if it is unused.
  4. If static data must be updated remotely, use a direct CQL connection to the owning node's table.

Example fix

// before
INSERT INTO vt (pk, ck, static_col) VALUES (1, 'a', 'x');
// after
INSERT INTO vt (pk, ck) VALUES (1, 'a');  -- update static_col via base table instead
Defensive patterns

Strategy: validation

Validate before calling

// Strip static column assignments before writing via the virtual table
if (insertStatement.includesStaticColumns())
    throw new IllegalArgumentException("Static columns not supported here; write via base table");

Try / catch

try { session.execute(write); }
catch (InvalidRequestException e) {
    if (e.getMessage().contains("Static rows are not supported"))
        // remove static column assignments and retry
}

Prevention

When it happens

Trigger: INSERT/UPDATE (apply) on the virtual table where the PartitionUpdate contains a static row — e.g. the user sets a static column, or a batch/write path populates static columns of the underlying schema.

Common situations: Writes generated from base-table-shaped tooling that includes static column assignments; schema changes that added static columns after the virtual-table workflow was built.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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