ycqlsh fails on COPY TO with got an unexpected keyword argument 'encoding'

[hstenzel]

ycqlsh fails with <stdin>:1:<lambda>() got an unexpected keyword argument 'encoding' in scenarios where "standard" cqlsh succeeds.

It's the same failure if I run it using the docker image or the local install. Being explicit about encoding has no bearing.

# ycqlsh fails
12:15 $ ~/cqlsh-3.10-yb-6/bin/ycqlsh $ADDR $PORT -k $KEYSPACE -e 'COPY table TO STDOUT WITH HEADER = TRUE;'
. . .
<stdin>:1:<lambda>() got an unexpected keyword argument 'encoding'

# but regular cqlsh succeeds
12:15 $ cqlsh $ADDR $PORT -k $KEYSPACE -e 'COPY table TO STDOUT WITH HEADER = TRUE;'
. . .

[ndeodhar]

Thanks for reporting @hstenzel. I'm able to reproduce this problem.
For now, as a workaround, you can run ycqlsh --debug. For example:

12:26 $ ./bin/ycqlsh --debug
Using CQL driver: <module 'cassandra' from '/Users/yugabyte/code/yugabyte-db/thirdparty/installed/common/cqlsh/bin/../lib/cassandra-driver-internal-only-3.13.0.post0-743d942c.zip/cassandra-driver-3.13.0.post0-743d942c/cassandra/__init__.py'>
Using connect timeout: 5 seconds
Using 'utf-8' encoding
Using ssl: False
Connected to local cluster at 127.0.0.1:9042.
[ycqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
ycqlsh> copy sample.t to STDOUT;
Detected 12 core(s)
Using 11 child processes

Starting copy of sample.t with columns [a].
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Closing parent cluster sockets
Created connection to ('127.0.0.1',) with page size 1000 and timeout 10 seconds per page
1
2
3
Processed: 3 rows; Rate:      29 rows/s; Avg. rate:      29 rows/s
3 rows exported to 0 files in 0.115 seconds.
ycqlsh> exit

Without --debug, I get the same error that you mentioned:

12:25 $ ./bin/cqlsh 
Connected to local cluster at 127.0.0.1:9042.
[ycqlsh 5.0.1 | Cassandra 3.9-SNAPSHOT | CQL spec 3.4.2 | Native protocol v4]
Use HELP for help.
ycqlsh> copy sample.t to STDOUT;
<lambda>() got an unexpected keyword argument 'encoding'
ycqlsh> exit;

@OlegLoginov , the issue seems to be related to these lines:
In YB copyutil.py:

self.printmsg = printmsg if self.fname is not None or direction == 'from' or DEBUG \
            else lambda _, eol='\n': None

In Cassandra (https://github.com/apache/cassandra/blob/ebba613b0b34ea338eed508a3ba6cbb235986fd9/pylib/cqlshlib/copyutil.py#L95):

self.printmsg = printmsg if self.fname is not None or direction == 'from' or DEBUG \
            else swallowmsg

def swallowmsg(msg, eol='', encoding=''):
    None

We should fix copyutil.py.

[hstenzel]

I was able to work around it with hstenzel/cassandra@996f164

Using --debug as a workaround isn't very helpful since the point is to save the data into a csv file and all output is on stdout -- the debug output is not on stderr as one would expect.

The patch is one I pulled from https://issues.apache.org/jira/browse/CASSANDRA-8675

[hstenzel]

Another data point is that I tried the workaround with --debug, adding a hacky sed to strip out the non-csv results, and it kinda worked. However, there was a follow-on issue.

Whereas cqlsh was able to round-trip csv files containing the \ character, ycqlsh with --debug led to corrupted data when the contents of the string contains \n. Every \n was transformed into \\n.

I'm using COPY $table TO/FROM STDOUT WITH HEADER = FALSE AND NULL = '<NULL>' AND ESCAPE = '\"';

I suspect this is a different bug.