av9ash/GitBugs huggingface dataset:
Bug: Test failure: repair_tests/preview_repair_test.py::TestPreviewRepair::test_preview
Status: Open
Priority: Normal
Created: 07/Jun/22 14:12

The Python dtest {{repair_tests/preview_repair_test.py::TestPreviewRepair::test_preview}} is flaky at least in {{trunk}}, with a flakiness < 1%.

I haven't seen the failure on Jenkins but on [this CircleCI run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1662/workflows/b5753cdb-2d08-44d0-9caf-79b5fd0b01f4] for CASSANDRA-17458.

The failure can also be [reproduced in the multiplexer|https://app.circleci.com/pipelines/github/adelapena/cassandra/1667/workflows/60ba0ade-7e4e-4728-a7ff-3872f2a1903c], with 7 failures in 5000 iterations:

{code}
test teardown failure
Unexpected error found in node logs (see stdout for full details). Errors: [[node3] 'ERROR [CompactionExecutor:3] 2022-06-06 10:58:08,720 JVMStabilityInspector.java:68 - Exception in thread Thread[CompactionExecutor:3,5,CompactionExecutor]\njava.util.ConcurrentModificationException: null\n\tat java.util.HashMap$HashIterator.nextNode(HashMap.java:1469)\n\tat java.util.HashMap$KeyIterator.next(HashMap.java:1493)\n\tat java.util.AbstractCollection.toArray(AbstractCollection.java:141)\n\tat com.google.common.collect.ImmutableSet.copyOf(ImmutableSet.java:211)\n\tat org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy.getSSTables(SizeTieredCompactionStrategy.java:341)\n\tat org.apache.cassandra.db.compaction.PendingRepairManager.getRepairFinishedCompactionTask(PendingRepairManager.java:271)\n\tat org.apache.cassandra.db.compaction.PendingRepairManager.getNextRepairFinishedTask(PendingRepairManager.java:359)\n\tat org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:65)\n\tat org.apache.cassandra.db.compaction.PendingRepairHolder.getNextRepairFinishedTask(PendingRepairHolder.java:159)\n\tat org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:200)\n\tat org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:291)\n\tat org.apache.cassandra.concurrent.FutureTask$2.call(FutureTask.java:98)\n\tat org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)\n\tat org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)\n\tat io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat java.lang.Thread.run(Thread.java:748)']
{code}
Bug: Refactor python code from bin to pylib
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Apr/22 15:06
Resolved: 22/Sep/22 08:29

The cassandra/bin directory consists of only executable shell scripts, except for 2000+ lines of Python code in cqlsh.py.  This code would be reuseable if refactored to cassandra/pylib.  

We'll retain a minimal runner cqlsh.py.
Bug: Frozen maps may be serialized unsorted, causing inability to query later
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/May/22 20:09
Resolved: 20/May/22 11:04

CASSANDRA-7859 introduced the ability to use frozen collections as parts of primary keys. This +requires+ all frozen maps to be persisted with their entries sorted by the map keys. If the map is +not+ sorted correctly, it becomes impossible to project all of the map values out of the map using the map projection/selection syntax. For example, the select below would fail if the map was not sorted correctly and the higher-valued key was persisted first:
{code:sql}
CREATE TABLE test.test (k text, c frozen<map<text, text>>, PRIMARY KEY (k, c));
INSERT INTO test.test (k, c) VALUES ('key', {'z':'second_value', 'a':'first_value'});
SELECT k, c['a'] from test.test where k='key' -- c['a'] would return NULL here
{code}

Additionally, if you attempted to select just that row by using the complete map value in a WHERE clause, which is also supported, it would return no rows unless the map provided by the query processor just happened to be sorted the same way as the persisted value.

However, there is a bug in Maps.java where we don't actually use a SortedMap in {{Maps.Value#fromSerialized}}, which manifests if a client sends an unsorted map as a bound parameter to a query on insert or select. In either case, the map may not be sorted correctly, leading to either invalid data being persisted to disk (in the INSERT case) or the query not being able to be executed/returning 0 rows even though a row _should_ exist (SELECT).

This bug affects any usage of parameterized queries (tested with the DataStax driver, and was originally discovered when using the CQLSSTableWriter code to write data locally).
Bug: When a node is bootstrapping it gets the whole gossip state but applies in random order causing some cases where StorageService will fail causing an instance to not show up in TokenMetadata
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/May/22 23:21
Resolved: 01/Jun/22 17:51

When gossip state has a causal relationship, the order the state gets applied needs to match this relationship, and when it doesn’t it can cause bootstrap (which apply the whole state in an empty state) to see missing data or instances
Bug: Adding support for TLS client authentication for internode communication
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Apr/22 14:37
Resolved: 24/May/22 20:14

Same keystore is being set for both Inbound and outbound connections but we should use a keystore with server certificate for Inbound connections and a keystore with client certificates for outbound connections. So we should add a new property in Cassandra.yaml to pass outbound keystore and use it in SSLContextFactory for creating outbound SSL context.
Bug: Create a new node tool supporting force compaction of a partition
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jun/22 00:13
Resolved: 07/Nov/22 22:21

Need to create new tool called {*}nodetool forcecompact{*}. The syntax of the command is
*nodetool forcecompact keyspace table <list of partition keys ignoring the gc_grace_seconds>.*

One of the use cases of the tool is to handle the bad partitions which may contain too many tombstones. The tool will compact all the sstables containing the partition keys. In addition, by ignoring the {*}gc_grace_seconds{*}, it will help purge the tombstones faster.
Bug: Remove "--frames" option when generating javadoc
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jun/22 04:26
Resolved: 01/Aug/23 17:05

JDK17 doesn't support this option and it seems not quite necessary. For forward compatibility I propose we can remove this option.

Related JDK issue: [https://bugs.openjdk.org/browse/JDK-8215599]

I volunteer to prepare a patch if this is in a good direction.
Bug: Fix flaky org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/May/22 14:14
Resolved: 06/Sep/22 17:01

The test is flaky on 4.1:
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1604/workflows/243a20a5-eda2-4c28-95e8-ab6c4f85a891/jobs/10911


{code:java}
junit.framework.AssertionFailedError: expected:<0> but was:<1>
	at org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.lambda$testConnectionsAreRejectedWithInvalidConfig$81c80a4a$1(InternodeEncryptionEnforcementTest.java:91)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)
{code}
Bug: Fix a few config parameters after the Paxos improvements commit
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Apr/22 19:07
Resolved: 11/May/22 01:21

After committing the Paxos improvements, it was identified that the following configuration parameters need additional work:
 * repair_request_timeout_in_ms - can be removed
 * paxos_auto_repair_threshold_mb - I think it can be also removed; to be confirmed with the author

Discussed a bit in Slack and on this PR - https://github.com/apache/cassandra/commit/d2923275e360a1ee9db498e748c269f701bb3a8b
Bug: sstabledump errors when dumping data from index
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jun/22 14:14
Resolved: 19/Jun/23 13:01

{code:java}
cqlsh> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
cqlsh> CREATE TABLE ks1.tb1 ( id text, name text, primary key (id));
cqlsh> CREATE INDEX IF NOT EXISTS ON ks1.tb1(name);
cqlsh> INSERT INTO ks1.tb1 (id, name ) VALUES ( '1', 'Joe');
cqlsh> exit
./bin/nodetool flush
./tools/bin/sstabledump data/data/ks1/tb1-1c3c5f10ee4711ecab82eda2f44200b3/.tb1_name_idx/nb-1-big-Data.db 
[
  {
    "partition" : {
      "key" : [ "Joe" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 17,
        "clustering" : [ ] } ] } ]Exception in thread "main" java.lang.UnsupportedOperationException
        at org.apache.cassandra.db.marshal.PartitionerDefinedOrder.toJSONString(PartitionerDefinedOrder.java:87)
        at org.apache.cassandra.db.marshal.AbstractType.toJSONString(AbstractType.java:187)
        at org.apache.cassandra.tools.JsonTransformer.serializeClustering(JsonTransformer.java:372)
        at org.apache.cassandra.tools.JsonTransformer.serializeRow(JsonTransformer.java:269)
        at org.apache.cassandra.tools.JsonTransformer.serializePartition(JsonTransformer.java:235)
        at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
        at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
        at java.util.Iterator.forEachRemaining(Iterator.java:116)
        at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
        at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
        at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
        at org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:113)
        at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:214) {code}
Bug: Fix BulkLoader to load  entireSSTableThrottle and entireSSTableInterDcThrottle
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Jun/22 17:11
Resolved: 19/Aug/22 21:27

{{entire_sstable_stream_throughput_outbound and entire_sstable_inter_dc_stream_throughput_outbound}} were introduced in CASSANDRA-17065.They were added to the LoaderOptions class but they are not loaded in BulkLoader as {{throttle}} and {{interDcThrottle are. }}{{As part of this ticket we need to fix the BulkLoader, also those properties should be advertised as MiB/s, not megabits/s. This was not changed in CASSANDRA-15234 for the bulk loader because those are not loaded and those variables in LoaderOptions are disconnected from the Cassandra config parameters and unused at the moment. }}
It will be good also to update the doc here - [https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html,|https://cassandra.apache.org/doc/latest/cassandra/operating/bulk_loading.html]
{{and add a test that those are loaded properly when used with the BulkLoader. }}
{{CC [~frankgh] }}
Bug: Flaky org.apache.cassandra.cql3.KeywordTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/May/22 15:59
Resolved: 18/May/22 06:47

The tests in this class fail very often with:
h3.  
{code:java}
Error Message
Timeout occurred. Please note the time in the report does not reflect the time until the timeout.

Stacktrace
junit.framework.AssertionFailedError: Timeout occurred. Please note the time in the report does not reflect the time until the timeout. at java.util.Vector.forEach(Vector.java:1277) at java.util.Vector.forEach(Vector.java:1277) at java.util.Vector.forEach(Vector.java:1277) at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53) at java.util.Vector.forEach(Vector.java:1277)
{code}
 

I don't think I've seen them failing in CircleCI, but I see different tests from the class in Jenkins timing out. 

Example:

[https://jenkins-cm4.apache.org/job/Cassandra-4.1/5/testReport/junit/org.apache.cassandra.cql3/KeywordTest/test_keyword_MODIFY_isReserved_true_/]
Bug: Fix flaky dtest - org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/May/22 10:59
Resolved: 14/Jul/22 15:21

{code}
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions were thrown during test
	at org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
	at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
	at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:239)
	at org.apache.cassandra.distributed.upgrade.BatchUpgradeTest.batchTest(BatchUpgradeTest.java:53)
	Suppressed: java.lang.RuntimeException: java.lang.AssertionError
		at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
		at org.apache.cassandra.distributed.impl.Instance.lambda$null$6(Instance.java:495)
		at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
		at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
		at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
		at java.lang.Thread.run(Thread.java:748)
	Caused by: java.lang.AssertionError
		at org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
		at org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
		at org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
		at org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
		at org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
		at org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
		at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
		at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
{code}

https://ci-cassandra.apache.org/job/Cassandra-4.1/34/testReport/org.apache.cassandra.distributed.upgrade/BatchUpgradeTest/batchTest/
Bug: Make resumable bootstrap feature optional
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jun/22 20:22
Resolved: 28/Oct/22 18:49

From the patch I'm working on:

{code}
# In certain environments, operators may want to disable resumable bootstrap in order to avoid potential correctness
# violations or data loss scenarios. Largely this centers around nodes going down during bootstrap, tombstones being
# written, and potential races with repair. By default we leave this on as it's been enabled for quite some time,
# however the option to disable it is more palatable now that we have zero copy streaming as that greatly accelerates
# bootstraps. This defaults to true.
# resumable_bootstrap_enabled: true
{code}

Not really a great fit for guardrails as it's less a "feature to be toggled on and off" and more a subset of a specific feature that in certain circumstances can lead to issues.
Bug: Fix flaky test - org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Apr/22 14:32
Resolved: 06/Jun/22 17:18

h3. Error Message

/127.0.0.3 appending to commitlog traces expected:<100> but was:<98>
h3. Stacktrace
{noformat}
junit.framework.AssertionFailedError: /127.0.0.3 appending to commitlog traces expected:<100> but was:<98> at org.apache.cassandra.distributed.test.MessageForwardingTest.lambda$mutationsForwardedToAllReplicasTest$8(MessageForwardingTest.java:92) at java.base/java.util.HashMap.forEach(HashMap.java:1336) at org.apache.cassandra.distributed.test.MessageForwardingTest.mutationsForwardedToAllReplicasTest(MessageForwardingTest.java:91) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
Bug: forceCompactionForTokenRange when using a wrapped range may include sstables not within that range
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Apr/22 20:50
Resolved: 12/Aug/22 09:46

This was found in CASSANDRA-17537

When you compact the range (32, 31] this should include everything BUT 32, but in the test org.apache.cassandra.db.compaction.LeveledCompactionStrategyTest#testTokenRangeCompaction it found that SSTables with the bounds (32, 32) were getting included in the set of SSTables to compact
Bug: Fix flaky test - org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Apr/22 14:48
Resolved: 07/Jun/22 21:17

h3. Error Message

['LOAD' is expected to be null] expected:<null> but was:<Value(122848.0,28)>
h3. Stacktrace

junit.framework.AssertionFailedError: ['LOAD' is expected to be null] expected:<null> but was:<Value(122848.0,28)> at org.apache.cassandra.db.virtual.GossipInfoTableTest.assertValue(GossipInfoTableTest.java:174) at org.apache.cassandra.db.virtual.GossipInfoTableTest.testSelectAllWithStateTransitions(GossipInfoTableTest.java:96)
Bug: CQL writetime and ttl functions should be forbidden for multicell columns
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/May/22 10:16
Resolved: 27/Jun/22 14:34

CQL {{writetime}} and {{ttl}} functions are currently forbidden for collections, frozen or not. Also, they are always allowed for UDTs, frozen or not:
{code}
CREATE TYPE udt (a int, b int);
CREATE TABLE t (k int PRIMARY KEY, s set<int>, fs frozen<set<int>>, t udt, ft frozen<udt>);

SELECT writetime(s) FROM t; -- fails
SELECT writetime(st) FROM t; -- fails
SELECT writetime(t) FROM t; -- allowed
SELECT writetime(ft) FROM t; -- allowed
{code}
This is done by checking in [{{Selectable.WritetimeOrTTL#newSelectorFactory}}|https://github.com/apache/cassandra/blob/cassandra-4.0.4/src/java/org/apache/cassandra/cql3/selection/Selectable.java#L250] whether the column is a collection or not. However, I think that what we should check is whether the column is multi-cell. That way the function would work with frozen collections and UDTs, and it would reject unfrozen collections and UDTs:
{code}
SELECT writetime(s) FROM t; -- fails
SELECT writetime(st) FROM t; -- allowed
SELECT writetime(t) FROM t; -- fails
SELECT writetime(ft) FROM t; -- allowed
{code}
Bug: Fix leak of non-standard Java types in our Exceptions as clients using JMX are unable to handle them
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/May/22 18:30
Resolved: 26/Sep/22 15:43

This is a continuation of CASSANDRA-17638 where we fixed leaks introduced during development of 4.1 to ensure no regressions.

This ticket is to fix a few leakages which are there since previous major versions, not 4.1 regressions. 

{_}setRepairSessionMaxTreeDepth{_}(exists since 3.0) and _setRepairSessionSpaceInMegabytes(since 4.0)_

 in the DatabaseDescriptor. 

checkValidForByteConversion and _validateMaxConcurrentAutoUpgradeTasksConf (both since 4.0)_

 are used in both setters and on startup. They shouldn't throw ConfigurationException in the setters. 

There might be more but those are at least a few obvious I found in the DatabaseDescriptor.

CC [~dcapwell]
Bug: Fix org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams-cdc (from org.apache.cassandra.db.compaction.CompactionsCQLTest-cdc)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/May/22 23:24
Resolved: 06/Jun/22 11:33

{color:#172b4d}[https://ci-cassandra.apache.org/job/Cassandra-4.1/5/testReport/org.apache.cassandra.db.compaction/CompactionsCQLTest/testLCSThresholdParams_cdc_2/]{color}
h3.  
{code:java}
Error Message
expected:<50> but was:<51>

Stacktrace
junit.framework.AssertionFailedError: expected:<50> but was:<51> at org.apache.cassandra.db.compaction.CompactionsCQLTest.testLCSThresholdParams(CompactionsCQLTest.java:419) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Bug: Paxos v2 Linearizability Violation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Apr/22 14:23
Resolved: 18/Oct/22 15:14

﻿The version of Paxos introduced recently had a subtle mistake that introduced a linearizability flaw that has been detected by the simulator, and also a flaw with the simulator has been found that may erroneously report a linearizability violation.

The true linearizability fault is quite simple: fast read permissions were erroneously being escalated to promises when an incomplete proposal was discovered. This was likely due in part to the naming of the state {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will be used to re-propose this proposal using the promises we have obtained. The fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.

The false linearizability fault was triggered when two different competing incomplete proposals were reproposed multiple times, with the winning proposal being the one with the lower original ballot, and the proposal with the higher ballot having been successfully proposed to a majority of nodes but across multiple different ballots (so that no single ballot reached a majority), while the most recently successful ballot (at a minority) was the older original ballot. The range movement validation logic looked only at the original ballot, and since it saw the higher original ballot as having reached a majority perceived that it should have become persistent, when in fact the older ballot did so.
Bug: CQLSH help topic links are broken between textile and online files
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Apr/22 00:32
Resolved: 08/Aug/23 16:25

CQLSH help topics opens a generic CQL page, not the specific topic.  This happens when docs are not installed locally, and it tries to open the online version.

The file cqlsh.py has:

{{    # default location of local CQL.html}}
{{    if os.path.exists(CASSANDRA_PATH + '/doc/cql3/CQL.html'):}}
{{     ....}}
{{    else:}}
{{    # fallback to online version}}
{{    CASSANDRA_CQL_HTML = CASSANDRA_CQL_HTML_FALLBACK}}

For example,

{{cqlsh> help truncate;}}

opens the page:

[https://cassandra.apache.org/doc/latest/cassandra/cql/index.html#truncateStmt]

but there is no information about 'truncate' on that page and the anchor #truncateStmt doesn't exist.

the correct page anchor is:

[https://cassandra.apache.org/doc/latest/cassandra/cql/ddl.html#truncate-statement]

The local file anchors appear they may be incorrect as well:

[https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile#truncate]

To reproduce this, 'pip install cqlsh' on a machine without a Cassandra package install.