Skip to content

NODEJS-691 Fix generated timestamp on retry#438

Merged
absurdfarce merged 2 commits intoapache:masterfrom
luccailliau:master
Oct 1, 2025
Merged

NODEJS-691 Fix generated timestamp on retry#438
absurdfarce merged 2 commits intoapache:masterfrom
luccailliau:master

Conversation

@luccailliau
Copy link
Copy Markdown
Contributor

@luccailliau luccailliau commented Apr 26, 2025

Hello @absurdfarce,

There is an issue with timestamps generated by timestamp generators in DefaultExecutionOptions.
No matter if the request is prepared or not, any retry, including speculative execution, will generate a new timestamp for the query when starting a new execution for the same request object.

As interpreted by Cassandra, the latest timestamp take precedence. Then, queries executed and marked as successful can be overwritten by past queries when retrying the execution.

The user feels that it is a retry but in fact, it is a new query.

This is done by the WriteQueue when calling request.write(...) which call writeQueryParameters(...) and then getOrGenerateTimestamp() which always generate a new timestamp for each new execution. It should generate one and use it for each consecutive calls to make a retry operation in Cassandra.

I did not write any tests for this change since I don't have a proper setup and configuration on my side which cause tests to fail. I think testing on the client side only, like this is enough:

const request = new ExecuteRequest(...);

const firstBuffers = request.write(...);
const secondBuffers = request.write(...);

assert.deepStrictEqual(firstBuffers, secondBuffers); // At least on the parts for the timestamp

Thank you very much,
Have a good day,

Luc

@absurdfarce
Copy link
Copy Markdown
Contributor

absurdfarce commented Apr 27, 2025

Note: this PR is in reference to NODEJS-691

@absurdfarce absurdfarce changed the title Fix generated timestamp on retry NODEJS-691 Fix generated timestamp on retry Apr 30, 2025
@absurdfarce
Copy link
Copy Markdown
Contributor

I agree that this is an issue (and a pretty significant one) but I'm inclined to say we should address it at a different spot. More details can be found on NODJES-691; I'd like to keep the conversation going there as much as possible since this issue isn't actually constrained to the code being modified here.

Copy link
Copy Markdown
Contributor

@SiyaoIsHiding SiyaoIsHiding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@absurdfarce
Copy link
Copy Markdown
Contributor

Agree with @SiyaoIsHiding; this looks right to me. Test run with these changes was as expected so I think we're good to go here!

@absurdfarce absurdfarce merged commit acea0b9 into apache:master Oct 1, 2025
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants