Panic in vtgate with OLAP mode

[aquarapid]

Could be related to #8687 , but logging separately since this has a clean repro:

• Recent main (Version: 12.0.0-SNAPSHOT (Git revision 4358c6a85e branch 'main')
• Unsharded keyspace called keyspace with primary and 2 replicas (no vschema):

$ vtctlclient -server localhost:15999 ListAllTablets
zone1-0000000100 keyspace1 0 primary 192.168.0.134:15100 192.168.0.134:17100 [] 2021-08-26T18:21:22Z
zone1-0000000101 keyspace1 0 replica 192.168.0.134:15101 192.168.0.134:17101 [] <null>
zone1-0000000102 keyspace1 0 replica 192.168.0.134:15102 192.168.0.134:17102 [] <null>

• Create a table, insert some data, and verify:

$ mysql -u user  -h 127.0.0.1 -P 15306 -p  keyspace1
.
.
mysql> create table t1 (c1 bigint not null, c2 bigint not null, c3 bigint, primary key(c1));                      
Query OK, 0 rows affected (0.07 sec)

mysql> insert into t1 (c1,c2) values (20,21);                                                                
Query OK, 1 row affected (0.01 sec)

mysql> select * from t1;
+----+----+------+
| c1 | c2 | c3   |
+----+----+------+
| 20 | 21 | NULL |
+----+----+------+
1 row in set (0.01 sec)

• Connect to database again (NOTE: not using a dbname), issue a USE for our keyspace, switch to OLAP and do show tables:

$ mysql -u user  -h 127.0.0.1 -P 15306 -p  
.
.
.
mysql> use keyspace1;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> set workload=olap;
Query OK, 0 rows affected (0.00 sec)

mysql> show tables;
ERROR 2013 (HY000): Lost connection to MySQL server during query

• Panic from vtgate log:

I0826 11:21:23.745757   30998 tablet_health_check.go:111] HealthCheckUpdate(Serving State): tablet: zone1-102 (192.168.0.134) serving false => true for keyspace1/0 (REPLICA) reason: healthCheck update
E0826 11:26:02.754808   30998 server.go:303] mysql_server caught panic:
runtime error: index out of range [0] with length 0
runtime/panic.go:88 (0x435324)
vitess.io/vitess/go/vt/vtgate/engine/rename_fields.go:78 (0xeb89c8)
vitess.io/vitess/go/vt/vtgate/engine/rename_fields.go:87 (0xed121c)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:330 (0xfaf6aa)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:376 (0xfcf8ee)
vitess.io/vitess/go/vt/vttablet/queryservice/wrapped.go:198 (0xdee1d8)
vitess.io/vitess/go/vt/vttablet/grpctabletconn/conn.go:195 (0x121cd24)
vitess.io/vitess/go/vt/vttablet/queryservice/wrapped.go:196 (0xdee349)
vitess.io/vitess/go/vt/vtgate/tabletgateway.go:270 (0xfb3d8f)
vitess.io/vitess/go/vt/vttablet/queryservice/wrapped.go:194 (0xdebee1)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:375 (0xfcfaa7)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:516 (0xfd0328)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:521 (0xfb0628)
vitess.io/vitess/go/vt/vtgate/scatter_conn.go:374 (0xfafb64)
vitess.io/vitess/go/vt/vtgate/executor.go:1483 (0xfa1064)
vitess.io/vitess/go/vt/vtgate/vcursor_impl.go:447 (0xfba564)
vitess.io/vitess/go/vt/vtgate/engine/send.go:158 (0xec1b1e)
vitess.io/vitess/go/vt/vtgate/engine/rename_fields.go:91 (0xeb8a4c)
vitess.io/vitess/go/vt/vtgate/executor.go:1113 (0xf9d999)
vitess.io/vitess/go/vt/vtgate/vtgate.go:429 (0xfc69ec)
vitess.io/vitess/go/vt/vtgate/plugin_mysql_server.go:219 (0xfa5d29)
vitess.io/vitess/go/mysql/conn.go:1255 (0xcf0b13)
vitess.io/vitess/go/mysql/conn.go:1240 (0xcf06f5)
vitess.io/vitess/go/mysql/conn.go:877 (0xced41e)
vitess.io/vitess/go/mysql/server.go:474 (0xd14391)
vitess.io/vitess/go/mysql/server.go:286 (0xd1afa4)
runtime/asm_amd64.s:1371 (0x472740)

EDIT: Updated description to reflect that this may have nothing to do with health check, it just happens to occur right after vtgate logs a health check message.

[aquarapid]

A similar error (with the same traceback) occurs when you connect without a dbname, set workload to OLAP and then issue a USE:

$ mysql -u user  -h 127.0.0.1 -P 15306 -p  
.
.
mysql> set workload=olap;                  
Query OK, 0 rows affected (0.00 sec)

mysql> use keyspace1;
Lost connection to MySQL server during query

However, connecting to the database directly, setting workload to OLAP and then just starting queries does work:

$ mysql -u user  -h 127.0.0.1 -P 15306 -p keyspace1
.
.
mysql> set workload=olap;                  
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t1;
+----+----+------+
| c1 | c2 | c3   |
+----+----+------+
| 20 | 21 | NULL |
+----+----+------+
1 row in set (0.00 sec)