Cassandra restores coordinator query visibility

A running query can disappear from an observation interface without disappearing from the executor doing its work. Cassandra 4.1.5 repairs that gap for coordinator tasks in system_views.queries. The task was present, but a wrapper had lost the debugging information the virtual table needed to recognize it.

The May 20 release record and tagged changelog establish the maintenance release. Alongside query visibility, it fixes persistent disagreement after equivalent schema updates and hint handling when a node goes down repeatedly. Each correction concerns information retained across an internal transition.

I am interested in Cassandra's ability to support active-active systems, but that does not make every distributed workload a good reason to deploy it. For workloads that do need it, the ability to inspect a coordinator's actual work is part of making the operating model manageable. An empty observation result should not be mistaken for evidence that no relevant task exists.

A future wrapper lost debugging identity

CASSANDRA-19577 identifies DebuggableTasks at the coordinator that were not preserved through creation of FutureTasks in TaskFactory. The query virtual table asks the shared executor pool for running tasks. Without the debugging information surviving that transformation, it cannot see the query in the expected form.

The issue notes that one execution path already propagated RunnableDebuggableTask, while the relevant submission path also needed to do so. That difference is a reminder that equivalent-looking task APIs can create different observable behavior. Executing a task and submitting it for future completion both schedule work, but their wrappers still need to preserve the metadata used by inspection tools.

The release makes coordinator queries visible through the existing table. It does not introduce a new query language or a separate monitoring service. An operator can use the virtual table while understanding that the correction repairs a missing category of tasks in its results.

SELECT * FROM system_views.queries;

That statement requests the table's current contents. The fix improves what it can report at the coordinator, rather than making the result a historical archive of every query. The mechanism described in the issue concerns running tasks inspected through the executor pool.

Equivalent schema can still have different digests

CASSANDRA-19578 concerns two nodes issuing the same schema creation statement. A logical comparison can find no difference between the resulting schema definitions. The underlying mutations in system_schema can nevertheless carry different timestamps, which matter to the digest used for agreement.

An optimization for empty schema changes looked only at the logical difference. That allowed the digest-relevant state to remain inconsistent even though the visible definitions appeared equivalent. The issue calls the result a pseudo schema disagreement that did not resolve on its own.

This explains why comparing the rendered CQL definitions is insufficient to establish that the agreement mechanism has converged. The digest represents persisted schema state, including information beyond the logical definition returned by a schema comparison. Skipping work based only on that comparison can preserve a difference that the agreement mechanism still observes.

The issue limits this defect to the 4.1 line. Version 4.1.5 supplies the correction. It would be inaccurate to describe every concurrent schema operation or every Cassandra release as subject to this particular failure.

I find the distinction useful because it explains a disagreement that otherwise looks contradictory. Operators can see matching schema while the database reports different digests. The missing information is the underlying mutation state, not necessarily a table definition that somebody forgot to inspect.

A second outage inherited an old hint window

CASSANDRA-19495 describes a node going down, returning, and later going down again. Hints work for the first outage. In the reported scenario, the second outage occurs more than the maximum hint window after the first began, and hints are no longer recorded as expected.

The investigation points to the earliest-hint tracking keyed by host UUID. If that retained time is not cleared when the node returns, the next outage can appear to have already exhausted its allowed hinting interval. The problem concerns which outage the remembered time describes.

The changelog summarizes this as a hints-delivery correction for a repeatedly failing node. The issue adds an important detail to that summary. In its reproduction, the hint is not stored at all and no hint file appears. Delivery cannot recover a mutation that the system never recorded as a hint.

This is separate from guaranteeing unlimited recovery after arbitrary downtime. A configured hint window still expresses a limit. The maintenance correction makes repeated availability transitions use the appropriate state, instead of carrying an earlier outage's timing into a later one.

Internal transitions must preserve the right information

Query submission should retain debugging identity, schema updates should preserve agreement-relevant state, and a node's return should end the timing state associated with its previous outage. Those are different mechanisms with different symptoms. Their common operational consequence is that an apparently ordinary transition can leave a later component reasoning from incomplete or stale information.

For a deployment using Cassandra's distributed model, 4.1.5 improves both visibility and recovery behavior within the existing interfaces. The query table can recognize coordinator tasks after wrapping, the schema path can resolve digest differences beyond logical definitions, and hint handling no longer treats the reported repeated outage as a continuation of the earlier one.