av9ash/GitBugs huggingface dataset:
Bug: TestCqlsh.test_protocol_negotiation needs to be updated for v5
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 25/Feb/21 14:57
Resolved: 25/Feb/21 15:09

https://ci-cassandra.apache.org/job/Cassandra-trunk/290/testReport/junit/dtest.cqlsh_tests.test_cqlsh/TestCqlsh/test_protocol_negotiation/

{quote}
AssertionError: assert 'Native protocol v4' in 'Connected to test at 127.0.0.1:9042.\n[cqlsh 5.0.1 | Cassandra 4.0-beta5-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]\nUse HELP for help.\ncqlsh> cqlsh:system> '
{quote}
Bug: Snapshot_test.py DTests failing
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/21 22:01
Resolved: 25/Feb/21 14:28

[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/623/workflows/1c89bd58-bcd1-45dc-b923-3aba245a78a6/jobs/3451]

These failures are also observed for other patches in Jenkins dev (weird but they are not seen failing in the latest builds and they are failing with completely unrelated different patches...)

[https://jenkins-cm4.apache.org/job/Cassandra-devbranch/375/#showFailuresLink]

[https://jenkins-cm4.apache.org/job/Cassandra-devbranch/368/]

Jenkins dev history for one of the tests:

https://jenkins-cm4.apache.org/job/Cassandra-devbranch/375/testReport/junit/dtest-novnode.snapshot_test/TestArchiveCommitlog/test_archive_commitlog_with_active_commitlog/history/
Bug: Unable to bootstrap/join new nodes to existing 4.0 cluster
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 27/Jan/21 02:22
Resolved: 08/Feb/21 06:35

Trying to add a new node to an existing 4.0 cluster gets stuck in bootstrap/joining permanently with no clear error.

Version: 4.0-beta4 (issue also seen in 4.0-beta3, and NOT seen in 3.11.x) and Java 8 (Open JDK 1.8.0_275)
Topology: 3 rack single DC using EC2Snitch, 1 seed node per rack
Relevant cassandra.yaml settings: 
{code}
auto_bootstrap: true (implicit)
seeds contains the same 3 nodes on all nodes
num_tokens: 16
allocate_tokens_for_local_replication_factor: 3
server_encryption_options.internode_encryption: all
server_encryption_options.enabled: true
server_encryption_options.optional: false
server_encryption_options.require_client_auth: true
client_encryption_options.enabled: true
client_encryption_options.optional: false
client_encryption_options.require_client_auth: true
{code}

Scenario: 
* Bring up the 3 seed nodes to create a new cluster. 
* Add a user keyspace: create keyspace test with replication = \{ 'class': 'NetworkTopologyStrategy', 'us-east-1-dc': 3 }; and insert some test data. 
* Wait at least 10 minutes after the initial 3 seed nodes come up (nodes will join if they are brought up at the same time as the seeds, but not if they are brought up later). 
* Start cassandra on a fourth node. 

Cassandra begins to bootstrap but does not ever finish (I have left this running overnight) and does not exit nor log any errors. Nodetool status from any node shows new node as UJ. Nodetool netstats from new node shows receiving file from test keyspace at 100% received. Logs show bootstrap starting and streaming starting, but then nothing/no errors.

Worth noting here that I have also tried this with allocate_tokens_for_local_replication_factor disabled and still have this issue. I have also tried this without any user keyspace/data, just completely empty cluster and still have this issue. The only way I seem to be able to bring up a decently sized cluster on 4.0 is to disable allocate_tokens_for_local_replication_factor (to avoid collisions as mentioned in other issues) and bring up all nodes at about the same time, or use auto_bootstrap: false. I have no issue adding a new node in a similar fashion to a 3.11.x cluster.
Bug: Fix flaky test mixedModeReadColumnSubsetDigestCheck - org.apache.cassandra.distributed.upgrade.MixedModeReadTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Feb/21 21:30
Resolved: 08/Feb/21 21:33

https://app.circleci.com/pipelines/github/dcapwell/cassandra/860/workflows/bde81400-ed6d-4d9c-8447-3dd33b14cddd/jobs/5117

{code}
junit.framework.AssertionFailedError: Found Digest Mismatch
	at org.apache.cassandra.distributed.upgrade.MixedModeReadTest.checkTraceForDigestMismatch(MixedModeReadTest.java:89)
	at org.apache.cassandra.distributed.upgrade.MixedModeReadTest.lambda$mixedModeReadColumnSubsetDigestCheck$0(MixedModeReadTest.java:63)
	at org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:171)
	at org.apache.cassandra.distributed.upgrade.MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck(MixedModeReadTest.java:76)
{code}
Bug: Fix schema aggreement race conditions in in-JVM dtests 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jan/21 15:48
Resolved: 28/Jan/21 14:55

There there are two race conditions in in-JVM dtest schema agreement, which are causing test failures:

1. First is caused by the fact we’re starting waiting for schema propagation already after the schema agreement was reached (which was resulting into us endlessly waiting for an agreement that has already been established);
 2. The other one was because the callback to notify about successful agreement can be triggered already after the other node has notified about it, and control flow might have moved cluster to a different configuration.

Example of exception:
{code:java}
Caused by: java.lang.IllegalStateException: Schema agreement not reached
	at org.apache.cassandra.distributed.impl.AbstractCluster$ChangeMonitor.waitForCompletion(AbstractCluster.java:?)
	at org.apache.cassandra.distributed.impl.AbstractCluster.lambda$schemaChange$5(AbstractCluster.java:?)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:?)
	at java.util.concurrent.FutureTask.run(FutureTask.java:?)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:?)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:?)
	at org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:?)
	at java.lang.Thread.run(Thread.java:?)
{code}
Bug: Correctly serialize all request responses - CASSANDRA-15946 followup
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Jan/21 04:11
Resolved: 17/Feb/21 23:02

When receiving a message, a 4.0 dtest instance reserializes  messages to pass them through the dtest message filtering.
 
 The 4.0 internode messaging refactor does not expect to have to re-serialize response
 messages, so the workaround in CASSANDRA-15946 was just to register the ReadResponse serializer for all REQUEST_RESPONSE messages, however request response is used for other responses too.

I'm attaching a patch that demonstrates the issue by adding a simple Paxos upgrade test to generate a PrepareResponse message that crashes the ReadResponse serializer, then reverts CASSANDRA-15946 and re-users the messaging service serialization method that checks the request callback if a serializer is not defined.
Bug: Update lib/jflex-1.6.0.jar to match upstream jflex-1.6.0.jar
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jan/21 19:59
Resolved: 20/Jan/21 15:45

jflex-1.6.0.jar was added to lib/ when SASI was added, as part of CASSANDRA-10661

The file in lib/ does not match the upstream file.
Bug: Reduce new reserved keywords introduced since 3.0
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/21 00:23
Resolved: 12/Feb/21 05:21

Building on CASSANDRA-16398, for users upgrading from 3.0 to 4.0 there have been a few new reserved keywords added that can cause problems with schema changes and queries in existing applications. Reducing the number of new reserved words makes upgrades easier for users.

{code:java}
K_DEFAULT
K_MBEAN
K_MBEANS
K_NEGATIVE_INFINITY
K_NEGATIVE_NAN
K_POSITIVE_INFINITY
K_POSITIVE_NAN
K_REPLACE
K_SCHEMA
K_UNSET
{code}

I think they can all be removed from the ReservedWords lists (where present) and added to {{basic_unreserved_keyword}} with the exception of the {\{NAN}} and \{{INFINITY}} as there could be ambiguity between a selected field and a nan/infinity literal.

To validate I've written a test that extracts the keywords from the parser tokens and verifies that any non-reserved keywords can be used as table and column names for regular tables and materialized views. It isn't exhaustive but provides a good sense check.
Bug: Table Metrics table in "doc/source/operating/metrics.rst" cannot be rendered
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jan/21 05:21
Resolved: 01/Feb/21 22:02

The page, [https://cassandra.apache.org/doc/latest/operating/metrics.html#table-metrics], is missing the table for table metrics. 

The cause is that the "=" in the docs source that defines the table is not properly aligned.
Bug: Unable to ALTER KEYSPACE while decommissioned/assassinated nodes are in gossip
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Feb/21 20:56
Resolved: 12/Feb/21 17:43

As part of Transient Replication added in CASSANDRA-14404, {{ALTER KEYSPACE}} had a validation check added to verify no range movement was taking place.

The check requires all nodes to be in {{NORMAL}} state. When a node is decommissioned or assassinated then it will remain in gossip for 3 days in {{LEFT}} state (by default), preventing any keyspace alteration until it has expired from gossip, even though it is safe to make the change.

The validation condition should be changed to all nodes being in {{NORMAL}} or {{LEFT}} state instead.
Bug: trying to deploy cassandra on kubernetes using bitnami image
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 24/Feb/21 12:48
Resolved: 24/Feb/21 13:19

Hi team, 

 

Trying to deploy cassandra on the kubernetes cluster, pod getting up but suddenly going in to the error state. I am adding the error that I am getting in the logs.

 

INFO [main] 2021-02-24 12:46:56,408 DatabaseDescriptor.java:775 - Back-pressure is disabled with strategy org.apache.cassandra.net.RateBasedBackPressure\{high_ratio=0.9, factor=5, flow=FAST}.
WARN [main] 2021-02-24 12:46:56,453 SimpleSeedProvider.java:60 - Seed provider couldn't lookup host cassandra-0.cassandra-headless.roman-yb.svc.uhn7klr2c.local
ERROR [main] 2021-02-24 12:46:56,455 CassandraDaemon.java:803 - Exception encountered during startup: The seed provider lists no seeds.

 Please help as this is stuck.
Bug: Cannot start multiple repair sessions over the same sstables
Status: Resolved
Priority: Normal
Resolution: Incomplete
Created: 23/Feb/21 14:25
Resolved: 23/Feb/21 14:30

When starting the  repair (cassandra 3.11.9, _nodetool repair -full_) an error occurs
{quote}ERROR [ValidationExecutor:87] 2021-02-23 09:59:11,585 ActiveRepairService.java:561 - Cannot start multiple repair sessions over the same sstables
 ERROR [ValidationExecutor:87] 2021-02-23 09:59:11,585 Validator.java:268 - Failed creating a merkle tree for [repair #c71cbc30-75bd-11eb-b3bb-b73fcd17890a
 java.lang.RuntimeException: Cannot start multiple repair sessions over the same sstables
{quote}
but there is no active repair processes.
{quote}nodetool compactionstats
 pending tasks: 0

nodetool netstats
 Mode: NORMAL
 Not sending any streams.
 Read Repair Statistics:
 Attempted: 588586868
 Mismatch (Blocking): 1460468
 Mismatch (Background): 8022504
 Pool Name Active Pending Completed Dropped
 Large messages n/a 0 21545142 3
 Small messages n/a 0 59512600068 209
 Gossip messages n/a 0 5991347 488
{quote}
How can i start node repair?
Bug: Testcase SASIIndexTest failed on aarch64 platform
Status: Open
Priority: Normal
Created: 16/Jan/21 08:19

When run ant; ant test on aarch64 platform, SASIIndexTest failed，the output as follows:
{code:java}
[junit-timeout] Testsuite: org.apache.cassandra.index.sasi.SASIIndexTest
[junit-timeout] #
[junit-timeout] # A fatal error has been detected by the Java Runtime Environment:
[junit-timeout] #
[junit-timeout] #  SIGSEGV (0xb) at pc=0x0000000000000000, pid=4230, tid=0x0000ffffb1ba11f0
[junit-timeout] #
[junit-timeout] # JRE version: OpenJDK Runtime Environment (8.0_275-b01) (build 1.8.0_275-8u275-b01-0ubuntu1~18.04-b01)
[junit-timeout] # Java VM: OpenJDK 64-Bit Server VM (25.275-b01 mixed mode linux-aarch64 compressed oops)
[junit-timeout] # Problematic frame:
[junit-timeout] # C  0x0000000000000000
[junit-timeout] #
[junit-timeout] # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
[junit-timeout] #
[junit-timeout] # An error report file with more information is saved as:
[junit-timeout] # /home/cassandra/cassandra/hs_err_pid4230.log
[junit-timeout] #
[junit-timeout] # If you would like to submit a bug report, please visit:
[junit-timeout] #   http://bugreport.java.com/bugreport/crash.jsp
[junit-timeout] #
[junit-timeout] Testsuite: org.apache.cassandra.index.sasi.SASIIndexTest
[junit-timeout] Testsuite: org.apache.cassandra.index.sasi.SASIIndexTest Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec
[junit-timeout]
[junit-timeout] Testcase: org.apache.cassandra.index.sasi.SASIIndexTest:testTableRebuild:       Caused an ERROR
[junit-timeout] Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
[junit-timeout] junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
[junit-timeout]         at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout]         at java.util.Vector.forEach(Vector.java:1277)
[junit-timeout]         at java.lang.Thread.run(Thread.java:748)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.index.sasi.SASIIndexTest FAILED (crashed)
   [delete] Deleting directory /home/cassandra/cassandra/build/test/cassandra/commitlog:333
   [delete] Deleting directory /home/cassandra/cassandra/build/test/cassandra/data:333
   [delete] Deleting directory /home/cassandra/cassandra/build/test/cassandra/saved_caches:333
   [delete] Deleting directory /home/cassandra/cassandra/build/test/cassandra/hints:333

{code}
attached file hs_err_pid4230.log, finding the root cause
Bug: Fix topology corruption on joining nodes without DC in dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jan/21 06:51
Resolved: 19/Feb/21 16:40

Dtests with multi-dc setups don't update the topology properties file of a newly joining node without dc post cluster creation.

The new node will join dc1 but it's snitch will report the default snitch config as it doesn't get updated == dc1 == all nodes are in dc1 == there are no other dcs. That leads to bootstrap, token, startup,... problems. Let's see an example:
- populate [1, 1, 1]
- Node1 sees: dc1/ip1, dc2/ip2 and dc3/ip3
- Node2 sees: dc1/ip1, dc2/ip2 and dc3/ip3
- Node3 sees: dc1/ip1, dc2/ip2 and dc3/ip3
- Add a new Node4
- Node4 sees: dc1/ip1+ip2+ip3+ip4

All multi-dc dtests that add a node after cluster creation suffer this problem.

Solution: When a new node is added without specifying a dc in dtests check for existing dcs. If there are any force to specify one to update the topology file.
Bug: Version family is probably broken for Cassandra 2 and 3.11 in dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Feb/21 06:43
Resolved: 20/Feb/21 10:49

It looks like the version families are a bit confused - when we determine version family for the current build, we do:

{code:python}
    if current_version.vstring.startswith('2.0'):
        version_family = '2.0.x'
    elif current_version.vstring.startswith('2.1'):
        version_family = '2.1.x'
    elif current_version.vstring.startswith('2.2'):
        version_family = '2.2.x'
    elif current_version.vstring.startswith('3.0'):
        version_family = '3.0.x'
    elif '3.1' <= current_version < '4.0':
        version_family = '3.x'
    elif '4.0' <= current_version < '4.1':
        version_family = 'trunk'
    else:
        # when this occurs, it's time to update this manifest a bit!
        raise RuntimeError("4.1+ not yet supported on upgrade tests!")
{code}

but later, in the upgrade manifest we have:

{code:python}
indev_2_1_x = VersionMeta(name='indev_2_1_x', family='2.1', variant='indev', version='github:apache/cassandra-2.1', min_proto_v=1, max_proto_v=3, java_versions=(7, 8))
current_2_1_x = VersionMeta(name='current_2_1_x', family='2.1', variant='current', version='2.1.20', min_proto_v=1, max_proto_v=3, java_versions=(7, 8))

indev_2_2_x = VersionMeta(name='indev_2_2_x', family='2.2', variant='indev', version='github:apache/cassandra-2.2', min_proto_v=1, max_proto_v=4, java_versions=(7, 8))
current_2_2_x = VersionMeta(name='current_2_2_x', family='2.2', variant='current', version='2.2.13', min_proto_v=1, max_proto_v=4, java_versions=(7, 8))

indev_3_0_x = VersionMeta(name='indev_3_0_x', family='3.0', variant='indev', version='github:apache/cassandra-3.0', min_proto_v=3, max_proto_v=4, java_versions=(8,))
current_3_0_x = VersionMeta(name='current_3_0_x', family='3.0', variant='current', version='3.0.23', min_proto_v=3, max_proto_v=4, java_versions=(8,))

indev_3_11_x = VersionMeta(name='indev_3_11_x', family='3.11', variant='indev', version='github:apache/cassandra-3.11', min_proto_v=3, max_proto_v=4, java_versions=(8,))
current_3_11_x = VersionMeta(name='current_3_11_x', family='3.11', variant='current', version='3.11.9', min_proto_v=3, max_proto_v=4, java_versions=(8,))
{code}

later on in the code we have some manifest filtering:

{code:python}
            if filter_for_current_family and not origin_meta.matches_current_env_version_family and not destination_meta.matches_current_env_version_family:
                logger.debug("skipping class creation, origin version {} and destination version {} do not match target version {}, and --upgrade-target-version-only was set".format(origin_meta.name, destination_meta.name, VERSION_FAMILY))
                continue
{code}

This does not cause any problems for {{trunk}}, but when I tried to run some upgrade tests on 3.11 build, I could not do anything. 

Therefore we need to either change families in manifest as follows:
- 2.1 -> 2.1.x
- 2.2 -> 2.2.x
- 3.0 -> 3.0.x
- 3.11 -> 3.x

or change how we assign version family for the current build
Bug: DOC - Publish Changelog blog #4 Feb 2021
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Feb/21 10:53
Resolved: 16/Feb/21 11:15

Review [~Calico] 's Changelog blog #4 ([Google doc|https://docs.google.com/document/d/16fNtDKuSX9xKR26Jq9LUZuB4O0JoJfgD6iKHCT98QOQ/edit?usp=sharing]) to https://cassandra.apache.org/blog/.
Bug: Improve handling of failed prepared statement loading
Status: Open
Priority: Normal
Created: 12/Feb/21 07:03

In an internal DEV cluster, when going from 3.0 to 3.11 we have seen the following WARN logs constantly upon Cassandra startup.
{noformat}
...
WARN [main] 2021-02-05 09:25:06,892 QueryProcessor.java:160 - prepared statement recreation error: SELECT n,v FROM "Ts2Volatile60Min" WHERE k=? LIMIT ?;
WARN [main] 2021-02-05 09:25:06,895 QueryProcessor.java:160 - prepared statement recreation error: INSERT INTO "Ts2Final01Min" (k,n,v) VALUES (?,?,?) USING TIMESTAMP ?;
...
{noformat}

I guess 3.11 tries to pre-load prepared statements for tables which don't exist anymore. On how we got into this situation was our fault I think (Cas 3.0 => Upgrade 3.11 => Downgrade 3.0 => with 3.0 some tables got dropped => Upgrade 3.11.10).

Still, perhaps there is room for improvement when it comes to loading persisted prepared statements, which might fail.

I thought about:
* An additional {{nodetool}} option to wipe the persisted prepared statement cache
* Perhaps even make the startup code smarter in a way, when loading of a prepared statement fails, due to a table not being available anymore, then auto-wipe such entries from the {{prepared_statements}} system table

To get rid of the WARN log, I currently need to work directly on the "prepared_statements" system table, but I don't know if it is safe to run e.g. a TRUNCATE statement, thus currently, it seems we need to take each node offline, execute a Linux {{rm}} command on SSTables for the system table.
Bug: fault occurred in a recent unsafe memory access operation
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 10/Feb/21 09:39
Resolved: 10/Feb/21 09:51

Hi, testing Cassandra 4~beta4 and JDK 11, all nodes crashed with error of :
{code}
ERROR [MutationStage-55] 2021-02-10 01:07:15,015 AbstractLocalAwareExecutorService.java:166 - Uncaught exception on thread Thread[MutationStage-55,5,main]
java.lang.RuntimeException: java.lang.InternalError: a fault occurred in a recent unsafe memory access operation
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:104)
        at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:44)
        at org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:432)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
        at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
        at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.InternalError: a fault occurred in a recent unsafe memory access operation
{code}

Using Azul Zing JDK:
zing-zst-8c.dkms.2.6.32-5.22.8.0.4.el.x86_64
zing-jdk11.0.0-20.08.101.0-1.x86_64

OS: CentOS 7, kernel 5.0.1 

The crash accrued after some stress tests on cluster.

Thank you, Yakir Gibraltar
Bug: Data mismatch across the nodes in the cluster
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Feb/21 15:23
Resolved: 09/Feb/21 15:30

Hi,

 

Recently I have came across one strange issue. On an existing cluster with 12 nodes, there were new nodes launched replacing the older ones. It was ensured that only one node was being added or removed at a time until it comes to healthy state. Once the process was completed, we found some data consistency issues in the cluster. Querying a table from some nodes gave back null results which wasn't expected. Is this expected behaviour? We are running Cassandra *3.11.3* version.

Though this problem was solved by running repairs, but it doesn't sound right. There wasn't any strange thing observed from the Cassandra logs (just a few timeouts spread over time which is quite normal when a cluster is running).
Bug: Remove the Jenkins plaintext reports
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jan/21 10:14
Resolved: 08/Feb/21 17:20

Remove the generation of the {{cassandra-test-report.txt}} plain text report (that was added in CASSANDRA-15729). 

The xml report is now at 3GB and too big to fit through any xsl transformation. It is only going to get bigger as more tests and test stages are added.

This size failure is seen in the pipeline logs as
{noformat}
docker run --rm -v /home/jenkins/jenkins-slave/workspace/Cassandra-trunk@2:/tmp apache_cassandra_ci/generate_plaintext_test_report
Warning: at xsl:stylesheet on line 4 column 49 of cassandra-test-report.xsl:  Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
 java.lang.IndexOutOfBoundsException: [660540429,660540717]
	at net.sf.saxon.tinytree.LargeStringBuffer.subSequence(Unknown Source)
	at net.sf.saxon.tinytree.TinyTextImpl.getStringValue(Unknown Source)
	at net.sf.saxon.tinytree.TinyParentNodeImpl.getStringValue(Unknown Source)
        …
{noformat}

In addition we can and do now archive everything to https://nightlies.apache.org/cassandra/ , solving the original requirements of CASSANDRA-15729 of providing a permanent archive of test results.