[Release] ScyllaDB 2026.2.8

Release Notes
, ,
1

The ScyllaDB team is pleased to announce the release of ScyllaDB 2026.2.8, a production-ready patch release for ScyllaDB 2026.2 Short Term Support (STS) Minor Feature Release.

More information on ScyllaDB Version Support Policy is available here.

Related Links

Bug Fixes

The following issues are fixed in this release.

Alternator

  • When a request was rejected for exceeding the per-shard concurrent-request limit (answered with RequestLimitExceeded), the connection could be closed even though the response had promised to keep it alive. A later, unrelated request that reused the same connection then failed with an unexpected disconnect. Rejected requests now leave the connection reusable, so clients no longer see spurious disconnects after hitting the concurrency limit. scylladb#31532

  • Disabling Streams on a table keeps its CDC data readable for 24 hours by retaining the underlying CDC log table, but ListTables incorrectly listed that retained log table (<table>_scylla_cdc_log) as if it were a regular table. ListTables now excludes retained CDC log tables, so it only returns the tables an application actually created. scylladb#31784

Compaction

  • Running compaction while a tablet merge was in progress could fail with an “Unable to remove input SSTable” error and abort. This case is now handled correctly, so compaction and tablet merges can run concurrently without aborting. scylladb#31284

  • In a related case, a newly produced SSTable could be picked up and removed by a second, unrelated compaction before the first compaction had finished with it, leading to the same “Unable to remove input SSTable” failure. Such SSTables are now protected from concurrent compaction until the first compaction releases them, closing this window. scylladb#31717

  • During a paged read of a partition that spans multiple pages, the per-page compaction statistics could miscount, causing the dead-partition count in page-statistics trace output to be reported as an incorrectly large number. This only affected the accuracy of trace statistics, not query results. Partitions continued from a previous page are now counted correctly, so page statistics are accurate. scylladb#31485

CQL

  • Tracing a statement that bound a null element inside a collection (for example a list or set) could crash the node. A null collection element is now rendered as null in trace output, matching the JSON output behavior, so tracing such statements is safe. scylladb#31628

  • With a prepared ALTER TABLE, CREATE MATERIALIZED VIEW, or ALTER MATERIALIZED VIEW statement, if the first execution failed, later executions of the same prepared statement skipped part of the table-property validation, allowing invalid options (such as an invalid compaction strategy) to be accepted. Property validation now runs on every execution, so invalid options are consistently rejected. scylladb#31685

  • A SELECT that combined a tuple range restriction on clustering columns with filtering could return wrong results when those clustering columns were declared with DESC (descending) order. Without a secondary index the query returned no rows; with a secondary index it could return exactly the rows that should have been excluded. Such queries now return the correct rows regardless of the clustering order. scylladb#31708

Materialized Views (MV)

  • After a node restart, the view builder could resume building an unfinished materialized view without first flushing its base table, on the assumption that the flush had already happened. When that assumption did not hold, some view updates could be missed, leaving the view out of sync with its base table. The base table is now always flushed when the view builder resumes building an existing view, so no updates are lost. scylladb#31515

Raft

  • A coordinator that lost leadership mid-operation could still complete a TRUNCATE or SNAPSHOT, in rare cases using state belonging to a different, later operation. This could let a replica execute a request that had already been finalized elsewhere, risking data loss. Such operations are now safely aborted when the coordinator is no longer valid, preventing this. scylladb#31521

Reliability

  • A node that fell behind in applying incoming cluster-membership (gossip) updates could accumulate an unbounded backlog of duplicated pending updates from its peers, eventually exhausting memory. Pending updates are now coalesced to at most one per node, so the backlog is bounded by the size of the cluster rather than by the volume of gossip traffic. scylladb#31618

  • Truncating a table on a disk that had run out of free commitlog space could hang indefinitely, because the truncate disabled the very compaction it needed to free that space before flushing. The ordering is now corrected so the truncate can complete instead of stalling. scylladb#31519

  • Under commitlog pressure, particularly with large writes, a timed-out internal segment allocation could leave a commitlog segment permanently unreleasable, and repeated occurrences could eventually deadlock the commitlog. Such segments are now returned to the pool instead of being stranded, preventing the deadlock. scylladb#31679

Repair

  • A user-requested repair over a token range that spanned several vnode ranges with different replica sets was only repaired against the replicas of the range’s last part, so replicas owning earlier parts of the range were left out. The repair was still recorded as complete in system.repair_history, which could allow repair-based tombstone garbage collection (tombstone_gc = {'mode': 'repair'}) to proceed on nodes that had not actually been repaired, risking data resurrection. Repair now splits the requested range along replica-set boundaries and records history only for sub-ranges that were fully repaired, so tombstone GC is gated on accurate information. scylladb#31480

  • A long-running user-requested repair on a vnode keyspace could block a concurrent topology operation (such as a decommission) until the node running the repair was restarted. Topology operations now abort such repairs so they can proceed; the aborted repair can simply be re-run afterwards. scylladb#31531

  • A non-numeric value for the ranges_parallelism repair option was silently treated as 0, which caused the repair to hang forever. Invalid and out-of-range values (below 1) are now rejected immediately with a clear “bad parameter” error instead of hanging. scylladb#31645

Service Levels

  • When using LDAPRoleManager, ATTACH SERVICE LEVEL could report success even though the attachment was not actually applied, so the service level had no effect and could not be found afterward. Service level attachments under LDAPRoleManager are now stored and retrieved correctly. scylladb#31481

Stability

  • A rare internal race in the task-management code could, in unlucky timing, cause a node to use memory that had already been freed, potentially crashing the node. The affected object is now kept alive for the duration of the operation, preventing this. scylladb#31374

Storage

  • If an object storage endpoint was configured without a resolvable AWS region (no aws_region and no AWS_DEFAULT_REGION), the node could silently disable all of its object storage endpoints instead of only the misconfigured one. Each endpoint is now parsed independently: a misconfigured endpoint is rejected with a clear error naming the missing setting, while all valid endpoints keep working. scylladb#31479

  • nodetool restore --sstables-file-list rejected an otherwise valid file list if it ended with a trailing newline, because the resulting empty line was treated as a file name. Empty lines are now ignored, so a trailing newline no longer prevents a restore from proceeding. scylladb#31484

  • After an SSTable component was rewritten, the reported on-disk size of the SSTable (sstable::bytes_on_disk()) could be inaccurate because it did not account for the original SSTable’s size. On-disk size is now tracked correctly across component rewrites. scylladb#31615

  • A backup could, in rare cases, crash the node if the table or keyspace being backed up was affected by concurrent activity during the upload. Backups now handle this safely and no longer risk crashing the node. scylladb#31714

  • A backup to an S3 endpoint that was throttling requests (for example under load-shedding) could exhaust its retries and fail the whole multipart upload, surfacing as a confusing “Failed to parse ETag list” error rather than indicating that the endpoint was overloaded. Backups now detect sustained throttling and briefly pause instead of adding more load, and use a longer retry backoff for throttling responses, making backups against a busy endpoint more resilient. scylladb#31668

Tablets

  • A table that grew large enough to need many more tablets could be left with too few, because tablet count was only ever increased up to double the current count at a time. In particular, once several tables shared a shard’s tablet budget, an oversized table could stay pinned at its current tablet count instead of splitting further. Tablet count now scales to the table’s actual size-based need, so large tables split as expected. scylladb#31111

  • During a replication-factor change, streaming from the source replicas was not counted against the per-shard streaming limit (tablet_streaming_read_concurrency_per_shard), so a single source shard could be asked to stream an unbounded number of tablets at once, overloading it. The per-shard streaming limit is now enforced consistently across all replicas involved, keeping streaming load bounded. scylladb#31709