Cassandra 5.0.5 aligns index readiness with node startup
Already built SAI indexes can become queryable before a restarted node accepts traffic. A separate fix publishes management information while bootstrap is still in progress.
A node can be up before the indexes needed by its queries are marked usable. Cassandra 5.0.5, released on 5 August, closes that transient gap for already built storage-attached indexes during restart. The release also restores access to a management interface during bootstrap, when operators need it to understand progress.
Cassandra's distributed availability is what draws me to it. These changes matter because availability has several observable conditions. A process accepting traffic, an index ready to answer a query and a management interface available for diagnosis do not automatically become ready together.
Restart bypassed the bootstrap-specific ordering
CASSANDRA-20732 describes two existing routes for making SAI indexes queryable. Index initialization can run asynchronously, and pre-join tasks run synchronously before a bootstrapping node becomes NORMAL. A previously bootstrapped node restarting does not rely on that same pre-join sequence.
The resulting interval was temporary but observable. A restarted node could begin accepting requests before its already built index became queryable. The index data did not necessarily need rebuilding, yet the readiness flag still lagged the node's availability.
The patch moves a validation opportunity into the request for the initialization task. During startup, it obtains the index group and checks which SSTables lack the required index. If none are missing, it marks the index queryable immediately.
That path records build success and returns a task with an already successful result. It avoids waiting for the asynchronous initialization task to establish a fact the synchronous check can already determine.
The distinction is between validating completed state and performing missing construction work. An index that still needs work continues through the initial-build path. The new shortcut is conditional on finding no SSTables requiring indexing.
Startup is an essential condition
The patch deliberately limits early queryability to startup. Its comment explains a different case that must not use the shortcut. A newly created index may cover a table whose existing data is only in memtables, with no SSTables yet.
In that case, an empty list of non-indexed SSTables does not prove the index represents all existing data. Treating the empty list as universal readiness could omit memtable data until a flush. The node's startup state therefore participates in the decision.
This is an example of why a readiness predicate needs context. A check over on-disk components cannot, by itself, establish completeness for every possible lifecycle phase. The same empty collection has a different implication during startup than during new-index creation over live memory state.
The implementation retains the build path's blocking flush for live memtables. That flush helps produce the on-disk index before marking an initially built index queryable. The new restart behavior does not remove that requirement from ordinary index creation.
My preference is for this explicit separation. Reusing already completed index work should not weaken the construction rules for a new index. The patch keeps the optimization attached to the lifecycle state that justifies it.
The test changes queryability without removing index data
The regression test creates an indexed table and writes data across ten SSTables. It confirms that an indexed query returns five matching rows. It then marks the index artificially non-queryable and verifies that the query fails.
After placing the node in STARTING mode, the test invokes index initialization. It returns the node to NORMAL and repeats the query, expecting the original five rows. This isolates queryability marking from whether the index files exist.
That is stronger evidence for this particular repair than a successful restart alone. A test that only reopened the table could eventually pass after asynchronous initialization. The regression needs the early validation path to restore usability before that delay determines the result.
Bootstrap management needs an earlier registration point
The separate CASSANDRA-19902 patch moves management-bean registration earlier in StorageService initialization. Registration no longer waits for the complete-initialization method to run.
The issue report records management commands failing during bootstrap because the StorageService bean was unavailable. This is a different kind of startup gap. The operator needs to inspect a process that has not yet finished joining, so publishing the interface only after completion defeats that use.
Its regression test pauses bootstrap and connects over JMX while the joining operation is still active. It obtains a StorageService proxy and checks the operation mode before allowing bootstrap to complete. The test therefore examines the interval that previously lacked the interface.
The release changelog includes both fixes among broader indexing and runtime corrections. The common operational result is more precise startup behavior. Completed index state can become usable earlier during restart, while management state remains inspectable during bootstrap.