av9ash/GitBugs huggingface dataset:
Bug: LGPL dependency in cassandra-all 3.11.10
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 26/Mar/21 14:28
Resolved: 01/Apr/21 04:34

Dear Cassandra devs.

While integrating Cassandra in Apache Hop functionality we found out that the cassandra-all maven package drags in an older version of jboss-logging via reporter-config3:
{code:java}
+- org.apache.cassandra:cassandra-all:jar:3.11.10:compile
|  +- com.addthis.metrics:reporter-config3:jar:3.0.3:compile
|  |  +- com.addthis.metrics:reporter-config-base:jar:3.0.3:compile
|  |  \- org.hibernate:hibernate-validator:jar:4.3.0.Final:compile
|  |     +- javax.validation:validation-api:jar:1.0.0.GA:compile
|  |     \- org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile

{code}
jboss-logging 3.1.0.CR2 is from November 2011 and the library only changed to APL in 2012.

[https://github.com/jboss-logging/jboss-logging/blob/master/src/main/resources/META-INF/LICENSE.txt]
Bug: do not use http maven repo defined by MAT
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 11/Jan/21 15:31
Resolved: 02/Apr/21 08:59

We have had strange, somewhat inexplicable issues during building with pulling from maven central via HTTP, which fails as HTTPS is now required.  We last hacked around this in acf8de28ce2f2871e30e4a55086a38d850470f3e, but it was just that, a hack.

The crux of the problem seems to come from MAT, according to https://stackoverflow.com/questions/59948747/maven-ant-task-transitive-pom-dependencies-and-https-issue

Indeed, in our build.xml here: https://github.com/apache/cassandra/blob/trunk/build.xml#L481 we are using the central definition it provides. I propose instead overriding this definition to "https://repo1.maven.org/maven2/" which fixes the build in every case I've tried during a bisect.
Bug: Fix flaky test_ttl_deletions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Mar/21 10:36
Resolved: 24/Mar/21 15:51

Flaky test in slow environments. See [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/362/testReport/junit/dtest-novnode.paging_test/TestPagingWithDeletions/test_ttl_deletions/]
Bug: cassandra-builds produce deb packages that require python 3.7
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Mar/21 14:56
Resolved: 05/Mar/21 14:30

Since the builds moved from depending on python 2 to  python 3, the packages that are produced by the [cassandra-builds project|https://github.com/apache/cassandra-builds] expect Python 3.7 to be installed on the target systems:
{noformat}
$ sudo dpkg -i cassandra_4.0~beta5-20210303gitd29dd643df_all.deb
(Reading database ... 117878 files and directories currently installed.)
Preparing to unpack cassandra_4.0~beta5-20210303gitd29dd643df_all.deb ...
Unpacking cassandra (4.0~beta5-20210303gitd29dd643df) over (4.0~beta5-20210303git25f3cf84f7) ...
dpkg: dependency problems prevent configuration of cassandra:
 cassandra depends on python3 (>= 3.7~); however:
  Version of python3 on system is 3.6.7-1~18.04.dpkg: error processing package cassandra (--install):
 dependency problems - leaving unconfigured
Processing triggers for systemd (237-3ubuntu10.38) ...
Processing triggers for ureadahead (0.100.0-21) ...
Errors were encountered while processing:
 cassandra{noformat}
The [test docker images|https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu1910_j11.docker#L35-L36] ship with both py36 and py38, which allows the install to pass nicely, but on a vanilla Ubuntu Bionic system, only Python 3.6 is installed.

We need to use debian buster images for builds that ship with python 3.6 so that the dependencies align with it.
Bug: IPMembershipTest.sameIPFailWithoutReplace fails with timeout
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Mar/21 19:37
Resolved: 19/Mar/21 21:40

https://ci-cassandra.apache.org/job/Cassandra-trunk/307/testReport/junit/org.apache.cassandra.distributed.test/IPMembershipTest/sameIPFailWithoutReplace/

{noformat}
java.lang.RuntimeException: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: localhost/0:0:0:0:0:0:0:1:9042 (com.datastax.driver.core.exceptions.TransportException: [localhost/0:0:0:0:0:0:0:1:9042] Cannot connect), localhost/127.0.0.1:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [localhost/127.0.0.1:9042] Operation timed out))
	at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:146)
	at org.apache.cassandra.stress.settings.StressSettings.getJavaDriverClient(StressSettings.java:114)
	at org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:66)
	at org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:154)
	at org.apache.cassandra.stress.StressAction.run(StressAction.java:56)
	at org.apache.cassandra.stress.Stress.run(Stress.java:155)
	at org.apache.cassandra.stress.Stress.main(Stress.java:63)
{noformat}
Bug: ValueAccessorTest.testSlice is flaky
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Mar/21 19:52
Resolved: 16/Mar/21 13:23

https://ci-cassandra.apache.org/job/Cassandra-devbranch/479/testReport/junit/org.apache.cassandra.db.marshal/ValueAccessorTest/testSlice/

Probably fairly rare, but the potential is there:


{quote}
Regression

org.apache.cassandra.db.marshal.ValueAccessorTest.testSlice
Failing for the past 1 build (Since In progress#479 )
Took 25 ms.
Error Message

Gave up after finding only 59 example(s) matching the assumptions

Stacktrace

java.lang.IllegalStateException: Gave up after finding only 59 example(s) matching the assumptions
{quote}
Bug: Running cqlsh against cassandra 3 throws error about beta flag not set
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/21 21:40
Resolved: 16/Mar/21 19:43

I just ran `cqlsh` from `trunk` commit 2aa22ba99dcc1dacb07b7af31b2664e7db839063 against a Cassandra 3.11.10 docker image.

I expected that the newer cqlsh would down-negotiate from the v5 protocol to the older v4 protocol.

Instead, I was surprised to get a server error about a beta protocol being used without `BETA_FLAG` being set. I unfortunately had to reboot my computer, so I lost the traceback but I can easily reproduce if needed.

I think what's happening is that this commit promoted v5 out of beta:
https://github.com/apache/cassandra/commit/c9d6c725dd0b4aa5693eb1c6d2221c28e9e99c6e#diff-9e4fe0cfd28004625a8006be8a0bdeab8cbdfb039449fb9501b15e8952577aaaL479

And then when it tries to contact the older cassandra version, the server complains that it received a request using the v5 protocol without this beta flag being set.

However, I was expecting that cqlsh would catch the error and down-negotiate to v4. Instead, it simply returns the error with no message about how to solve. As someone relatively new to `cqlsh`, I assumed at first there was no workaround except for downgrading my version of `cqlsh`. After some googling, I stumbled across a stackoverflow pointing toward the `--cqlversion` flag.

Given that this was the first cqlsh to support python 3, it means that anyone trying to use python 3 for cqlsh against cassandra 3.x will hit this weird error. There is no alternative if you want to use python 3.

My suggested fix is to catch the error and either prompt the user with something like _Perhaps you want to manually specify a different cql protocol version using the `--cqlversion` flag?_ or simply auto-down negotiate to version 4 (although I understand why auto-down-negotiating may not be the right move).
Bug: Drop unittest2 dependency since we no longer support python < 2.7
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/21 05:37
Resolved: 14/Mar/21 16:21

`cqlsh` has a dependency on `unittest2`.

But `unittest2` is simply a backport of python 2.7+ features to older pythons.

Given that support for Python 2.7 is itself now deprecated in favor of Python 3 support, there's no need to include the `unittest2` import... 

I opened a pull request fixing this here: https://github.com/apache/cassandra/pull/921
Bug: SimpleSeedProvider needlessly reloads the config
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 15/Mar/21 10:51
Resolved: 15/Mar/21 13:39

SimpleSeedProvider can use parameters passed in the constructor rather than reloads the config to get them. I'm nor sure why it was implemented by that, but I saw a test flakiness in this code path.
Bug: Cassandra dropped read message and dropped mutation message
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 15/Mar/21 01:04
Resolved: 15/Mar/21 01:07

We have a Cassandra cluster consisting of 6 catches (rhel 7.8). A dropped read message and a dropped mutation message appear on two nodes of our DBMS.

We check it using tpstats. Tried changing the GC mechanism to g1 and Increasing the timeouts.

How to fix it
Bug: Materialized Views: incorrect where clause reported for quoted identifiers
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Mar/21 13:45
Resolved: 11/Mar/21 16:54

I believe this is a regression from 3.11.

Given the following schema:

{noformat}
CREATE TABLE t1 ("theKey" int, "theClustering" int, "theValue" int, PRIMARY KEY ("theKey", "theClustering"));

CREATE MATERIALIZED VIEW mv1 AS SELECT * FROM t1 WHERE "theKey" IS NOT NULL AND "theClustering" IS NOT NULL AND "theValue" IS NOT NULL  PRIMARY KEY ("theKey", "theClustering");
{noformat}

And given the following query:

{noformat}
SELECT where_clause FROM system_schema.views ;
{noformat}

With 3.11, I get:

{noformat}
"theKey" IS NOT NULL AND "theClustering" IS NOT NULL AND "theValue" IS NOT NULL
{noformat}

But with current trunk, I get:

{noformat}
theKey IS NOT NULL AND theClustering IS NOT NULL AND theValue IS NOT NULL
{noformat}

Note how column names appear in their internal format, not in quoted form.

Note: the DataStax drivers rely on this info to rebuild the view's DDL query client-side; generated CQL is currently broken with Cassandra 4.0-trunk.
Bug: Bump cqlsh version to 6.0.0
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/21 23:23
Resolved: 11/Mar/21 17:18

For the Cassandra 4.x release series, please should bump the cqlsh version... This way users can report which version of cqlsh they're using, along with the protocol/server version.

It's been 5.0.1 for the cassandra 3.x series, so 6.0.0 probably makes sense because there are possible breaking changes depending on how CASSANDRA-16508 is resolved.

Right now, if a user says they're using `cqlsh` 5.0.1, we have no idea which release they're actually using because that version number hasn't been incremented for several releases, even though the code is changing.

I maintain a standalone version of `cqlsh` on PyPI for lighter-weight installs, and it'd be very helpful if the version was bumped.

I opened a PR here to fix it: https://github.com/apache/cassandra/pull/923

Although I wasn't sure if this should be set to 6.0.0 because 6.0.0-beta5 might be more appropriate if there's another beta release planned before GA.
Bug:  org.apache.cassandra.distributed.test.TopologyChangeTest failing with client timeout
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 05/Mar/21 19:56
Resolved: 09/Mar/21 07:54

Two tests failing with the same error, so I'm assuming they're related. 
testRestartNode[1: provision strategy=OneNetworkInterface]
testDecommission[1: provision strategy=OneNetworkInterface]

Feel free to split out if it ends up looking like something different.

https://ci-cassandra.apache.org/job/Cassandra-trunk/307/#showFailuresLink
https://app.circleci.com/pipelines/github/adelapena/cassandra/210/workflows/d21c7f93-58a7-4522-a505-0844304de67f/jobs/1700

{noformat}
com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: /127.0.0.1:9042 (com.datastax.driver.core.exceptions.OperationTimedOutException: [/127.0.0.1:9042] Operation timed out))
	at com.datastax.driver.core.ControlConnection.reconnectInternal(ControlConnection.java:270)
	at com.datastax.driver.core.ControlConnection.connect(ControlConnection.java:109)
	at com.datastax.driver.core.Cluster$Manager.negotiateProtocolVersionAndConnect(Cluster.java:1813)
	at com.datastax.driver.core.Cluster$Manager.init(Cluster.java:1726)
	at com.datastax.driver.core.Cluster.init(Cluster.java:214)
	at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:387)
	at com.datastax.driver.core.Cluster.connectAsync(Cluster.java:366)
	at com.datastax.driver.core.Cluster.connect(Cluster.java:311)
	at org.apache.cassandra.distributed.test.TopologyChangeTest.testRestartNode(TopologyChangeTest.java:176)
	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: ColumnFilter::toString doesn't return a valid CQL fragment
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Mar/21 12:16
Resolved: 10/Mar/21 17:46

This was changed in CASSANDRA-16415 to include indications about queried vs fetched reagular & static columns. However, the result is used by {{AbstractReadQuery::toCQLString}}, which causes it to produce an illegal query string.

This breaks a couple of dtests because they're looking for CQL strings in logs, which are no longer found:
* {{upgrade_tests/paging_test.py::TestPagingWithDeletions::test_failure_threshold_deletions}}
* {{cql_test.py::TestCQLSlowQuery}} has a couple of failing tests, {{test_local_query/test_remote_query}}

We should also check audit and fql logs (and any other place where {{toCQLString}} is used.
Bug: GSoC Blog Post
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Mar/21 00:09
Resolved: 10/Mar/21 19:59

Ticket to track review and publishing of GSoC blog post.

The blog post is available [google document|https://docs.google.com/document/d/1YLiyZ_quiDpCUyT3tyuWmVKiuj7h3HZdeBvqLzuMGes/edit]. This draft was announced on #cassandra-dev on slack and already reviewed by some community members.
Bug: GSoC Blog Post
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Mar/21 00:08
Resolved: 09/Mar/21 00:11

Ticket to track review and publishing of GSoC blog post.

The blog post is available [google document|https://docs.google.com/document/d/1YLiyZ_quiDpCUyT3tyuWmVKiuj7h3HZdeBvqLzuMGes/edit]. This draft was announced on #cassandra-dev on slack and already reviewed by some community members.
Bug: GSoC Blog Post
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Mar/21 00:07
Resolved: 09/Mar/21 20:19

Ticket to track review and publishing of GSoC blog post. 

The blog post is available on this [google document|https://docs.google.com/document/d/1YLiyZ_quiDpCUyT3tyuWmVKiuj7h3HZdeBvqLzuMGes/edit]. This draft was announced on #cassandra-dev on slack and already reviewed by some community members.
Bug: Node unreachable to each other with MUTATION message dropped
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Mar/21 08:37
Resolved: 09/Mar/21 19:57

Cluster setup: Ubuntu 18.04-LTS, cassandra-3.11.10. One DC, 3 nodes, 2 replication factor;

Using an injector to filter and drop MUTATION message between one node and the other two (drop MUTATION messages sent from node 1 to node 2, 3 and drop MUTATION messages sent from node 2, 3 to node 1). At the same time, inserted same key, different values on node 1 and node 2. When insertion happened, MUTATION message drops were caught on both node 1 and node2. Then we observed the different values for that key on two nodes and observed all three nodes disconnected from each other. 

 
{code:java}
./nodetool describecluster

/Cluster Information:Cluster Information: 
Name: Test Cluster Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch DynamicEndPointSnitch: enabled Partitioner: org.apache.cassandra.dht.Murmur3Partitioner 
Schema versions: UNREACHABLE: [10.0.1.8, 10.0.1.7, 10.0.1.9]
{code}
Bug: Python upgrade DTests fail in CircleCI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Mar/21 02:29
Resolved: 09/Mar/21 08:14

[https://app.circleci.com/pipelines/github/adelapena/cassandra/210/workflows/48230e6d-9fe0-4321-92b0-3709c86c5e16/jobs/1722]

It seems at some point in time JAVA8_HOME got lost from the CircleCI configuration. Upgrade Tests are not always run so that was missed. 

I tried just to ninja fix JAVA8_HOME by adding it back as part of the default variables as it was there before but then the build fails for Java 11 HIGHRES for missing Jars. It doesn't fail for Java 11 in MIDRES.

I have to check it further next week.
Bug: Add utest_system_keyspace_directory to CircleCI config template
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Mar/21 17:08
Resolved: 09/Mar/21 08:12

In CASSANDRA-14793 a new circle job config was added directly to the CircleCI base, LOWRES, MIDRES and HIGHRES config files, but not to the template file. When the config was regenerated for CASSANDRA-16474, the new job was lost. We should restore it and add it to the config template to avoid any reoccurrence.
Bug: Prevent and fail-fast any attempts to incremental repair cdc/mv tables
Status: Triage Needed
Priority: Normal
Created: 11/Jan/21 08:41

Running incremental repairs on CDC or MV tables [breaks|https://issues.apache.org/jira/browse/CASSANDRA-12888] them.

Attempting to run incremental repair on such should fail-fast and be prevented, with a clear error message.
Bug: Fix flaky test testMultiExpressionQueriesWhereRowSplitBetweenSSTables - org.apache.cassandra.index.sasi.SASIIndexTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Feb/21 18:29
Resolved: 08/Mar/21 10:54

https://app.circleci.com/pipelines/github/dcapwell/cassandra/862/workflows/d2b10373-5bd1-4895-a738-1c28587cae62/jobs/5136

{code}
junit.framework.AssertionFailedError: []
	at org.apache.cassandra.index.sasi.SASIIndexTest.testMultiExpressionQueriesWhereRowSplitBetweenSSTables(SASIIndexTest.java:589)
	at org.apache.cassandra.index.sasi.SASIIndexTest.testMultiExpressionQueriesWhereRowSplitBetweenSSTables(SASIIndexTest.java:468)
{code}
Bug: nodetool bootstrap resume completes successfully even if there is an error during bootstrap
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 05/Mar/21 18:51
Resolved: 05/Mar/21 18:55

"nodetool bootstrap resume” prints a relevant error message if the operation fails, but it then proceeds to return a normal error code. It ignores the ProgressEventType.ERROR message that arrives before COMPLETE. This also happens when we handle failed connections. BootstrapMonitor should at least track whether or not it has seen an error, which would allow us to throw when one occurs after signaling, and therefore to inform callers.
Bug: nodetool bootstrap resume completes successfully even if there is an error during bootstrap
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 05/Mar/21 18:46
Resolved: 05/Mar/21 18:51

"nodetool bootstrap resume” prints a relevant error message if the operation fails, but it then proceeds to return a normal error code. It ignores the ProgressEventType.ERROR message that arrives before COMPLETE. This also happens when we handle failed connections. BootstrapMonitor should at least track whether or not it has seen an error, which would allow us to throw when one occurs after signaling, and therefore to inform callers.
Bug: Multiple python dtest failures after promoting protocol v5 from beta
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Mar/21 16:34
Resolved: 04/Mar/21 14:53

After making v5 the default for connections where a preferred protocol version is not specified, a number of python dtests are failing in CI environments.

The issue appears to be with how the driver handles cases where the bytes read from the client socket doesn't constitute a complete frame (or to be more specific, the read buffer is exhausted whilst in the middle of reading a frame).
Bug: Debian packages are broken since py3 migration
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Mar/21 10:29
Resolved: 03/Mar/21 13:40

[Repair tests|https://app.circleci.com/pipelines/github/riptano/cassandra-rtest?branch=alex%2Fupgrade-tlp-cluster-python3] started to fail after the builds moved to Python3 in CASSANDRA-16396 due to deb packages failing to install on Ubuntu Bionic:
{noformat}
$ sudo dpkg -i cassandra_4.0~beta5-20210303git64f54f9fb0_all.deb
Selecting previously unselected package cassandra.
(Reading database ... 117650 files and directories currently installed.)
Preparing to unpack cassandra_4.0~beta5-20210303git64f54f9fb0_all.deb ...
Unpacking cassandra (4.0~beta5-20210303git64f54f9fb0) ...
dpkg: dependency problems prevent configuration of cassandra:
 cassandra depends on python (>= 3.6); however:
  Package python is not installed.
 cassandra depends on python3 (>= 3.7~); however:
  Version of python3 on system is 3.6.7-1~18.04.{noformat}
It seems like the following requirements are not correct:
{noformat}
Depends: openjdk-8-jre-headless | java8-runtime, adduser, python (>= 3.6), ${misc:Depends}, ${python3:Depends}{noformat}
I've changed this line to the following and got the deb packages to install correctly:
{noformat}
Depends: openjdk-8-jre-headless | java8-runtime, adduser, python3 (>= 3.6), ${misc:Depends}{noformat}
Bug: Cassandra not compatible with Oracle JRE 1.8.0_281 
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 04/Mar/21 23:41
Resolved: 05/Mar/21 00:06

In our environments, we need to patch with latest JRE when Oracle release its quarterly critical patch update.

We are running Teamwork cloud 19.0 SP4 and Cassandra 3.11.2 which is using JRE 1.8.0_251 at the moment.

All Java critical patch update after 251 seem to be incompatible with Cassandra . Latest Java 8 Update 281 is also not compatible .

When Cassandra windows service is started with java 8 update 281 installed , it throws error in the system and debug log (refer attached) and the service stops.

Please advise on how to keep the environment patched with latest update and also have cassandra running .
Bug: Cassandra 3.11.2 not compatible with Oracle JRE 1.8.0_281
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 04/Mar/21 23:37
Resolved: 05/Mar/21 00:05

In our environments, we need to patch with latest JRE when Oracle release its quarterly critical patch update.

We are running Teamwork cloud 19.0 SP4 and Cassandra 3.11.2 which is using JRE 1.8.0_251 at the moment.

All Java critical patch update after 251 seem to be incompatible with Cassandra . Latest Java 8 Update 281 is also not compatible .

When Cassandra windows service is started with latest Java 8 Update 281 installed , service does not start . Error is thrown in system and debug log files(Refer attached)

Please advise on how to keep the environment patched with latest update and also have cassandra running .
Bug: Fix selections of JDKs in debian docker images on arm64
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Feb/21 09:15
Resolved: 02/Mar/21 17:16

The debian docker [image|https://github.com/apache/cassandra-builds/blob/trunk/docker/buster-image.docker] used by the [cassandra-deb-packaging.sh|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-deb-packaging.sh] tries to set the jdk like
{code}
update-java-alternatives --set java-1.8.0-openjdk-amd64
{code}

This won't work on arm64.
Suggestion is to replace it with the following:
{code}
update-java-alternatives --set $(update-java-alternatives -l | cut -d" " -f1 | grep java-1.8)
{code}