[Proxy] IndexOutOfBoundsException: Index: 2, Size: 2 when connecting with DataGrip due to metadata quer

[CoffeeWithoutSugarX]

Which version of ShardingSphere did you use?

DBMS: MySQL (ver. 5.7.22-ShardingSphere-Proxy 5.5.2)
Case sensitivity: plain=exact, delimited=exact
Driver: MySQL Connector/J (ver. mysql-connector-java-8.0.25 (Revision: 08be9e9b4cba6aa115f9b27b215887af40b159e0), JDBC4.2)
Effective version: MySQL (ver. 5.7.25)

Ping: 1 sec, 188 ms
SSL: no

Which project did you use? ShardingSphere-JDBC or ShardingSphere-Proxy?

ShardingSphere-Proxy

Expected behavior

The proxy should correctly handle the metadata query sent by DataGrip and return the result set with the correct number of columns (3 columns), or handle the function calls gracefully without throwing an exception.

Actual behavior

When connecting to ShardingSphere Proxy using JetBrains DataGrip (2025.3), an IndexOutOfBoundsException occurs in DatabaseAdminQueryBackendHandler.

The error Index: 2, Size: 2 suggests that DataGrip is requesting 3 columns, but the internal logic in DatabaseAdminQueryBackendHandler (or the underlying AbstractMemoryQueryResult) only prepared 2 columns, causing a crash when accessing the 3rd column.

Reason analyze (If you can)

DataGrip sends the following SQL to check the current session status (database, schema, and user):

/* ApplicationName=DataGrip 2025.3 */ 
select database(), schema(), left(user(),instr(concat(user(),'@'),'@')-1)

This query requests 3 expressions:
1. database()
2. schema()
3. left(user()...)

The stack trace indicates the error happens at `DatabaseAdminQueryBackendHandler.getRowData(DatabaseAdminQueryBackendHandler.java:82)`. It seems the result row construction for this specific admin query does not match the column count expected by the execution engine.

        ### Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
        1. Start ShardingSphere Proxy (MySQL Protocol).
        2. Connect to the proxy using **JetBrains DataGrip** (e.g., version 2024.x or 2025.3).
        3. Observe the proxy logs or DataGrip console.


        ### Stack trace of logs

[ERROR] 2025-12-04 05:44:36.572 [ShardingSphere-Command-0] o.a.s.p.f.c.CommandExecutorTask - Exception occur: 

java.lang.IndexOutOfBoundsException: Index: 2, Size: 2

	at java.base/java.util.LinkedList.checkElementIndex(LinkedList.java:566)

	at java.base/java.util.LinkedList.get(LinkedList.java:487)

	at org.apache.shardingsphere.infra.executor.sql.execute.result.query.type.memory.AbstractMemoryQueryResult.getValue(AbstractMemoryQueryResult.java:76)

	at org.apache.shardingsphere.infra.merge.result.impl.transparent.TransparentMergedResult.getValue(TransparentMergedResult.java:44)

	at org.apache.shardingsphere.proxy.backend.handler.admin.DatabaseAdminQueryBackendHandler.getRowData(DatabaseAdminQueryBackendHandler.java:82)

	at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.getQueryRowPacket(MySQLComQueryPacketExecutor.java:130)

	at org.apache.shardingsphere.proxy.frontend.mysql.command.query.text.query.MySQLComQueryPacketExecutor.getQueryRowPacket(MySQLComQueryPacketExecutor.java:53)

	at org.apache.shardingsphere.proxy.frontend.mysql.command.MySQLCommandExecuteEngine.writeQueryData(MySQLCommandExecuteEngine.java:78)

	at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.doExecuteCommand(CommandExecutorTask.java:132)

	at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.executeCommand(CommandExecutorTask.java:121)

	at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:78)

	at com.alibaba.ttl.TtlRunnable.run(TtlRunnable.java:60)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

	at java.base/java.lang.Thread.run(Thread.java:1583)

at org.apache.shardingsphere.proxy.frontend.command.CommandExecutorTask.run(CommandExecutorTask.java:78)
at com.alibaba.ttl.TtlRunnable.run(TtlRunnable.java:60)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
     ```

[terrymanu]

Root Cause

MySQL no-FROM queries are routed to the admin branch (MySQLAdminExecutorCreator → UnicastResourceShowExecutor). This executor builds a QueryHeader with 3 columns, but the row data collected from the backend only has 2 columns. The mismatch
causes DatabaseAdminQueryBackendHandler to read a third column and throw an out-of-bounds exception.

Analysis

• Trigger: the session has no selected database (no schema in handshake/connection) and executes a no-FROM multi-expression query.
• In the admin branch, the column metadata shows 3 columns, but the row data list has only 2 elements; AbstractMemoryQueryResult.getValue accessing the 3rd column overflows.
• If the connection specifies a logic database or runs USE first, it follows the normal query path where columns and data align, so the issue does not appear.
• Official usage guidance: ShardingSphere-Proxy docs https://shardingsphere.apache.org/document/current/en/user-manual/shardingsphere-proxy/ recommend specifying a logic database on connect to avoid the admin branch for ordinary queries.

Conclusion (Fix Suggestion)

This is an admin-branch defect in 5.5.2. Fix by aligning column count and row data in UnicastResourceShowExecutor, or by skipping the admin branch for normal multi-expression no-FROM selects.

Example fix (5.5.2 path proxy/backend/type/mysql/src/main/java/org/apache/shardingsphere/proxy/backend/mysql/handler/admin/executor/UnicastResourceShowExecutor.java):

  private QueryResult createQueryResult() throws SQLException {
      List<MemoryQueryResultDataRow> rows = new LinkedList<>();
      int columnCount = getQueryResultMetaData().getColumnCount();
      while (databaseConnector.next()) {
          List<Object> data = databaseConnector.getRowData().getData();
          List<Object> aligned = new ArrayList<>(columnCount);
          aligned.addAll(data.size() >= columnCount ? data.subList(0, columnCount) : data);
          while (aligned.size() < columnCount) {
              aligned.add(null); // choose null or empty string per protocol expectation
          }
          rows.add(new MemoryQueryResultDataRow(aligned));
      }
      return new RawMemoryQueryResult(getQueryResultMetaData(), rows);
  }

Alternative (more conservative): in MySQLAdminExecutorCreator, for “no FROM + multi-expression” that is not a special function/system variable, return Optional.empty() so it goes through the normal query pipeline instead of the admin executor.

Community contributors are warmly invited to submit a PR to implement and test this fix—thanks for the report!