I have started looking into this, the main reason is that when the frame is created in JdbcResultSet, it is hardcoded to all rows (-1), that can change to in sync with FetchIterable value which is 100.
However, there's also a logic flow problem, in Avatica, every createStatement call is also RPC to the server, but the remote statement originally created was never used, and each call to Statement.execute() will actually create a brand new statement, hence the statement ID on remote vs local is out of sync during fetch. I plan to modify the parameter for prepareAndExecute to use StatementHandle instead of ConnectionHandle (where it store both the connection and statement ID) to recover the previous created statement.
Currently, the statement and connection cache are remain separate, I see a problem during invalidation of cache if they are kept apart, connection may close first before statement and making statement retrieved from statement cache being staled. One way is to extend the connection cache to include data structure that also store statement map, and there only remain a single cache policy. This is most likely a separate issue from this JIRA.