Cassandra 4.1 release candidate separates memtable errors from schema agreement
Cassandra 4.1-rc1 handles invalid local memtable definitions without discarding the shared table schema. Its fallback preserves the configured name while using the default implementation on the affected node.
A table schema can name a memtable configuration that one Cassandra node cannot instantiate. That creates a difficult failure boundary. Rejecting the shared schema because of a local configuration error can turn one node's missing implementation into disagreement about the table itself. Cassandra 4.1's first release candidate changes that behavior.
The 4.1-rc1 tag is dated November 22. Its changelog includes CASSANDRA-18040, which addresses schema mismatch caused by memtable API misconfiguration. The change illustrates the sort of integration issue that matters as a new extension API approaches release. A valid cluster-wide name and a usable node-local implementation are related, but they are not the same fact.
I like the flexibility of Cassandra's new memtable API when a deployment has a reason to use it. That flexibility introduces configuration distributed outside table schema. The release candidate's fallback makes the consequences of a local mistake more specific, while retaining an error that the operator must address.
Schema carries a name while YAML supplies an implementation
The memtable API uses named configurations defined in cassandra.yaml. A table selects one of those names through its memtable property. This lets the schema identify a configuration without embedding every implementation parameter in the table definition.
The API documentation in rc1 explains that the selection propagates to every node. Each node must then resolve the selected name against its own configuration and instantiate the associated class. A missing name or unusable class is local to that resolution process, even though the selected name belongs to shared schema.
Previously, those failures could cause rejection of the schema change. The updated documentation says an affected node logs an error and falls back to the default memtable configuration to avoid disagreement. Nodes running a version before 4.1 still reject the new schema change. The fallback therefore addresses misconfigured implementations on nodes supporting the API, not compatibility with an older server that lacks it.
That distinction is important when interpreting the feature as an upgrade aid. It does not permit a table to use the new property throughout an otherwise unsupported mixed-version cluster. The documentation continues to require upgrading all nodes before using the API and recommends changing the memtable selection through a separate ALTER statement.
The fallback retains the schema's selected name
The CASSANDRA-18040 patch adds MemtableParams.getWithFallback. It first calls the normal lookup method. If lookup raises ConfigurationException, the method logs an error and constructs a memtable parameter object using the default factory together with the original key.
Retaining the key is the central detail. If the node replaced the schema's name with a different name, its representation could differ from that of peers that resolved the requested configuration successfully. Keeping the original selection allows shared schema to remain consistent even while the affected node uses a different implementation factory locally.
The patch applies that method when SchemaKeyspace reconstructs table parameters from a schema row. That places fallback on the path that interprets existing shared schema. It does not replace every validation call with an unconditional default. The distributed test confirms that distinction by attempting the same alteration through differently configured nodes. Invalid configuration can still be rejected when a node handles a proposed alteration directly.
The error message identifies the invalid memtable name and asks the operator to correct its definition in cassandra.yaml. Fallback preserves the ability to interpret the table, but it is not a silent confirmation that the requested implementation is running. A deployment checking only schema agreement would miss that distinction.
The distributed test exercises asymmetric configuration
The patch adds a test with nodes whose local memtable configurations differ. The first node knows a configuration named testconfig that uses SkipListMemtable. A second node starts without the definition. The test first sends an alteration through that second node and expects a failure for the unknown name.
It then sends the alteration through the node that knows the configuration. That change succeeds there. The test compares rows from system_schema.tables on both nodes and requires equality. It separately checks that the node missing the definition emitted an error. Those assertions express the intended separation between preserving schema and reporting an implementation problem.
A third node starts with the same configuration name pointing to a nonexistent memtable class. It must accept the existing table schema and emit an error as well. The test finishes by writing to the table through each node. Missing configuration and an invalid class therefore exercise two distinct routes to the same fallback behavior.
This is useful evidence because a single-node test with a correct YAML file would not expose the disagreement. The failure needs a mismatch between the shared table setting and a particular node's configuration. The distributed test constructs that mismatch explicitly, including both handling an incoming change and joining with schema already present.
Fallback changes availability without validating deployment intent
Using the default factory keeps the local error from forcing a different schema representation. It does not establish that the selected alternative's expected behavior is present on every node. The operator still needs to correct the missing definition or class. If the alternative was selected for a particular implementation property, fallback means that property is not supplied by that node's requested factory.
I prefer a logged, specific fallback to schema disagreement for this failure, provided the deployment pays attention to the error. The distinction gives monitoring a concrete condition to report. Shared schema can agree while implementation resolution remains unhealthy on one node.
The release candidate includes other integration fixes, including starting Paxos automatic repair from CassandraDaemon and restoring the streaming keep-alive period on the Netty control channel. The memtable change has a particularly clear contract. It preserves a table's selected configuration name during schema loading and substitutes the default factory when local resolution fails, with an error identifying what needs repair.