[CASSANDRA-20028] METADATA_CHANGED is never set

• Type: Bug
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 4.0.x, 4.1.x, 5.0.x, 5.x
• Component/s: Legacy/CQL
• Bug Category: Correctness
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Assignee: Unassigned
• Reporter: João Reis
• Created: 25/Oct/24 15:26
• Updated: 25/Oct/24 17:24

Description

CASSANDRA-10786 added the METADATA_CHANGED flag to the v5 spec (ROWS RESPONSE). Drivers are supposed to handle this flag and update their locally cached prepared statement object with the new metadata.

As we're working to implement v5 support on GoCQL we are trying to trigger a scenario where C* returns this flag but we are unable to. Instead we receive an UNPREPARED which causes the driver to re-prepare the statement. This flag was added to avoid this scenario so I don't really understand if there is a bug somewhere or if the test case we're creating is not valid?

I ran the following steps against C* 4.0-rc1, 4.0.0 and 5.0.2 with the same results:

CREATE KEYSPACE testks WITH REPLICATION = { 'class': 'SimpleStrategy', 'replication_factor': 1 }

CREATE TABLE testks.testtable (id uuid PRIMARY KEY, txt TEXT)

INSERT INTO testks.testtable(id, txt) VALUES (uuid(), 'test')

// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618 
// RESULT METADATA ID: 1f685bd34ed0ba1e99ba6bd960da2545
SELECT * FROM testks.testtable

ALTER TABLE testks.testtable ADD (txt2 TEXT)

INSERT INTO testks.testtable(id, txt, txt2) VALUES (uuid(), 'test2', 'test222')

// this SELECT gets an UNPREPARED response from the server 
// instead of a ROWS response with the new metadata
//
// after RE-PREPARE: 
// PREPARED_ID: 2bea4b54ec20bd3533f7b91467abb618 
// RESULT METADATA ID: 87257e07eccd14a6c8e623012af9278a
SELECT * FROM testtable

Note that v5 support on gocql is still WIP so I imported gocql from this branch to test this with gocql.

I believe lukasz.antoniak was able to reproduce this with the java driver which has had v5 support for a while and got the same results, I'll ask him to post a comment on this ticket.

UPDATE

If the last SELECT is sent with the old metadata ID then we are able to see the METADATA_CHANGED flag but this would only occur if the driver does not update its local prepared statement object after the re-PREPARE. The expected behavior is that no re-PREPARE is needed in the first place.