Major Description
I noticed this case while playing around with sqlline, phoenix queryserver and avatica.
When sqlline starts up, it, among other things, fetches the columns to do some autocompletion magic in its shell. I noticed that this was always resulting in an error in Avatica's code, saying that the statement id wasn't found (the "fake" one -1)
I traced through this and believe there's a problem with how JdbcResultSet computes the maximum size of results put into a Frame. For the calls which use this fake statement id (getColumns, getCatalogs, getTableTypes, etc), a result set returned by the wrapped JDBC driver which is larger than 100 results will cause a Frame to be sent back to the client which informs it to fetch another frame (via the done member).
Concretely, if there are more than 100 columns to return in getColumns, the client will receive a Frame with done=false and 100 rows which will cause it to try to fetch another Frame of results. This will fail because we gave a fake statement ID which causes an exception in the server.
As I see it, there are two solutions:
- Create and cache a statement on these calls so that the fetch logic works as intended (the good solution)
- Send all of the results back in one frame (the quick hacky thing I just tested).