You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue originally identified and described by @ikehara in #127. The description of the problem is based on that work but the analysis of the root cause offered below is entirely my responsibility.
This process eventually filters down to set_keyspace_async() which sends a "USE \"[keyspace]\"" message on each active connection to correctly set server state
Recall that the keyspace argument passed through these functions is extracted directly from the set_keyspace result message. This value is just a basic string, but crucially it's provided from the server... meaning it represents a keyspace that has already been created (and thus must have a name matching the rules for keyspace names in Cassandra). As a result this name is just the string; there's no need to quote it or otherwise make it compatible with naming conventions.
To prove this you can run a simple Python client which executes a "USE [keyspace]" operation and monitor the traffic via Wireshark. Let's assume valid existing keyspaces on a Cassandra 4.0.2 server for what follows... at least that's what I tested all this on. Anyway, if you execute "use foo" and add some debugging you'll see the name "foo" returned in the set_keyspace result message. If you instead execute "use \"FOO\"" you'll see the name "FOO" returned via the result message. We had to wrap the value in double-quotes to clearly distinguish it from the lower-case keyspace but there's no need to do so when building the result message so it's just not done.
cql-proxy behaves slightly differently. When it builds it's set_keyspace result message it copies the value it parsed from the incoming statement. This means any double-quotes in the statement are also included in the message, which in turn leads to a follow-up "USE" statement from the driver which contains two double-quotes. This is a legit syntax error which means the cql-proxy parser fails with an error like this one:
{"level":"error","ts":1719267335.330605,"caller":"proxycore/connpool.go:74","msg":"unable to connect pool","host":"127.0.0.1:9042","error":"cql error: ERROR SYNTAX ERROR (code=ErrorCode SyntaxError [0x00002000], msg=line 1:4 no viable alternative at input '\"\"' (USE [\"\"]))","stacktrace":"github.com/datastax/cql-proxy/proxycore.connectPool\n\t/work/git/cql-proxy/proxycore/connpool.go:74\ngithub.com/datastax/cql-proxy/proxycore.(*Session).OnEvent.func1.1\n\t/work/git/cql-proxy/proxycore/session.go:120"}
Simply making the cql-proxy set_keyspace result message behave like the Cassandra version appears to completely address the issue.
The text was updated successfully, but these errors were encountered:
Issue originally identified and described by @ikehara in #127. The description of the problem is based on that work but the analysis of the root cause offered below is entirely my responsibility.
For the example below we'll assume version 3.29.1 of the DataStax Python driver for Apache Cassandra. Let's assume the following sequence of operations:
Recall that the keyspace argument passed through these functions is extracted directly from the set_keyspace result message. This value is just a basic string, but crucially it's provided from the server... meaning it represents a keyspace that has already been created (and thus must have a name matching the rules for keyspace names in Cassandra). As a result this name is just the string; there's no need to quote it or otherwise make it compatible with naming conventions.
To prove this you can run a simple Python client which executes a "USE [keyspace]" operation and monitor the traffic via Wireshark. Let's assume valid existing keyspaces on a Cassandra 4.0.2 server for what follows... at least that's what I tested all this on. Anyway, if you execute "use foo" and add some debugging you'll see the name "foo" returned in the set_keyspace result message. If you instead execute "use \"FOO\"" you'll see the name "FOO" returned via the result message. We had to wrap the value in double-quotes to clearly distinguish it from the lower-case keyspace but there's no need to do so when building the result message so it's just not done.
cql-proxy behaves slightly differently. When it builds it's set_keyspace result message it copies the value it parsed from the incoming statement. This means any double-quotes in the statement are also included in the message, which in turn leads to a follow-up "USE" statement from the driver which contains two double-quotes. This is a legit syntax error which means the cql-proxy parser fails with an error like this one:
Simply making the cql-proxy set_keyspace result message behave like the Cassandra version appears to completely address the issue.
The text was updated successfully, but these errors were encountered: