This issue is related to CASSANDRA-10786.
In short, when the table is altered (column is added), the wildcard queries keep the old result metadata and never return the added column for all but the very first client (as the very first client is the only one that receives UNPREPARED statement.
After adding result metadata to md5 on Cassandra side, as the message metadata on the client is never updated and new client ID of the re-prepared message is not saved anywhere, client would fall into the infinite re-prepare loop:
- (1) try running the query
- fail with UNPREPARED
- re-prepare (although without saving the new ID)
- go to (1)
I first tried to transparently swap the request when getting UNPREPARED, although that would mean that the original "outdated" prepared query would re-prepare no matter how many times it runs (even though results it returns would be correct). On the other hand, making changes in the BoundStatement itself (or in it's PreparedStatement) might lead to undesired behaviour on the client-side or even be prone to races (when request is sent assuming one id and metadata and came back after it got swapped).
Question is what'd be a good solution for such situation? Should we try and update the metadata everywhere in all bound statements or simply throw an exception and force the client to re-prepare the query?
I've attached the "test" file to illustrate the problem a bit better.
See the updated description of CASSANDRA-10786.