Fixing this for single-target queries is relatively straightforward to fix. When a query would be routed to the target that we previously routed to, we can proceed with the routing even if we haven't received the result. The only real problem here can be the failure to write the query while ongoing queries are in progress. The simplest solution in this case is to close the session which would prevent any out-of-order errors from being created.

For multi-target queries this is a more complex issue. Simple session variable assignments can be executed even if a previous statement is in progress as this is only appended to the session command queue of each backend and then executed. The problem here is the tracking of which session commands have been replied to.

For direct execution of prepared statements, the problem is harder: MaxScale needs to be able to translate the external PS ID generated by Maxscale to an internal value which maps to different PS ID values for each backend connection. The mapping is unique to each connection and can change for each connection depending on when the connection is created and whether reconnections take place. This means that direct execution of prepared statements might make the prepared statement code much more complex.

Implementing the code required to handle single-target pipelining of queries would be the first milestone for this. The universal pipelining of queries would be the second one as pipelining of multi-target queries brings much more limited benefits than the pipelining of single-target queries (batch execution of statements).