CNDB-15623: Only use write path for CDC tables in CassandraStreamReceiver if CDC is enabled on the node

[jkni]

What is the issue

Repairs use the local write path for streams on CDC-enabled tables, based on table schema. This interacts poorly with the separation of CNDB services.

What does this PR fix and why was it fixed

Only use the CDC write path for a stream if CDC is enabled in the node's configuration (as well as in the schema). This avoids attempting to use the local write path if commitlog-based CDC is not enabled.

[github-actions]

Checklist before you submit for review

• This PR adheres to the Definition of Done
• Make sure there is a PR in the CNDB project updating the Converged Cassandra version
• Use NoSpamLogger for log lines that may appear frequently in the logs
• Verify test results on Butler
• Test coverage for new/modified code is > 80%
• Proper code formatting
• Proper title for each commit staring with the project-issue number, like CNDB-1234
• Each commit has a meaningful description
• Each commit is not very long and contains related changes
• Renames, moves and reformatting are in distinct commits
• All new files should contain the DataStax copyright header instead of the Apache License one

[jkni]

Low test coverage is because we don't run the test suite with CDC enabled on PRs. I ran the test suite with CDC enabled and saw no additional failures.

[maxtomassi]

The change looks good to me. On the CNDB side we never enable CDC at the DatabaseDescriptor level, so the write path will not be triggered for cross-region repairs in Astra.

[sbtourist]

@maxtomassi @jkni As a side note, @jtgrabowski rightful concern about merging this without passing the quality gate (see Slack discussion) made me realize C* doesn't seem to have any kind of contract between DatabaseDescriptor#isCDCEnabled and the cdc schema property (well, not a clear one I could find at least); practically speaking, this means to me that there's no guarantee something will not break in the wild in case of the - admittedly odd but possible - configuration combination of DatabaseDescriptor#isCDCEnabled = false and cdc = true. Thoughts?

[maxtomassi]

As mentioned in Slack, the only relationship I see between the two properties are in here:

cassandra/src/java/org/apache/cassandra/schema/SchemaKeyspace.java

Lines 607 to 610 in b9c402b

	// Only add CDC-enabled flag to schema if it's enabled on the node. This is to work around RTE's post-8099 if a 3.8+
	// node sends table schema to a < 3.8 versioned node with an unknown column.
	if (DatabaseDescriptor.isCDCEnabled())
	builder.add("cdc", params.cdc);

Which seems to apply when a new table is created and when a table is altered. This means the cdc param will not be considered for tables in the schema keyspace if CDC is not enabled in the database descriptor.

[maxtomassi]

The test looks good to me, thanks for coming up with a way to cover the changes :)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jkni]

As discussed with Max, pinging Sergio for any further thoughts. Max can pick this up and merge if any issues are resolved before I'm online tomorrow.

[cassci-bot]

✔️ Build ds-cassandra-pr-gate/PR-2043 approved by Butler

---

Approved by Butler
See build details here

[sbtourist]

The new test looks great, thanks everyone!

[sbtourist]

To close the loop on #2043 (comment), we verified that even if CassandraStreamReceiver goes through the write path due to CDC being enabled on the schema, if CDC is not enabled on the DD, the node will produce no CDC logs; it follows that checking for DD#isCDCEnabled upfront in the receiver would yield the same end result (no CDC logs being produced). IOW, this change is backward compatible.