I think you’re on to something but I think we need to implement a fix at a different spot in the driver.

I’ll take a step back to explain my reasoning. Let’s look at a couple other drivers by way of comparison. The 4.x Java driver retry policy returns the request to be used on retry, although by default this is just the original request. The Python driver does something very similar. They’re able to do this because the driver (a) implements a “handler” object which governs the flow of a given request through it’s lifecycle and (b) maintains the message being sent as state within that handler… and this state includes the request timestamp. The Java driver manages request flow (including retries and speculative executions) via CqlRequestHandler while the message (and it’s timestamp) are represented as a discrete Java object (see the query message as an example). Python does something similar with different constructs; the ResponseFuture returned by exeucteX() calls manages the request lifecycle while request messages (and their timestamps) are encapsulated in Python objects.

The node.js driver does something similar… with an exception that’s pretty relevant to this discussion. There is a common request flow in RequestExecution. This logic looks very similar to the Java and Python examples but note that the stateful request contained here comes from the parent object, a RequestHandler. That request is created within Client but the crucial thing here is that it doesn’t track the request timetsamp. The serialization logic for that request is perfectly fine to let the timestamp be computed by the specified compute function… which gets into the logic you cite above.

It seems to me that the right way to fix this logic is to do something similar to what’s done in the other drivers and persist the timestamp as part of the underlying messages. I’d much rather make that change than modify how default timestamps are generated. This change shouldn’t have much of an impact on other driver functionality but we should definitely make sure we’re covered test-wise for any such change.

I’ll see if I can make this happen shortly… I completely agree with that the current behaviour is pretty clearly wrong on it’s face.

Thanks for the ticket and PR ! I’ll get these materials linked together and either or I will try to get a review for you shortly!