Detecting when a spanner read timestamp has expired - google-cloud-platform

Question

I am trying to build a cursor based pagination API on top of a spanner dataset. To do this I'm am using the read timestamp from the initial request to retrieve data and then encoding this into a cursor which can then be used to do an "Exact staleness" (https://cloud.google.com/spanner/docs/timestamp-bounds) read in subsequent paging requests.
For example, the processing of a request for the first page looks something like:
Transaction tx = spanner.singleUseReadOnlyTransaction();
tx.executeQuery(statement); // result set containing the first page of data
tx.getReadTimestamp(); // read timestamp that gets returned in a cursor
And for subsequent requests:
Transaction tx = spanner.singleUseReadOnlyTransaction(TimestampBound.ofReadTimestamp(cursorTs));
I'd also like to return a message to the user when the cursor timestamp has expired (the documentation linked to above states they are valid for roughly an hour) and to do this I have the following code:
try {
// process spanner result set
} catch (SpannerException e) {
if (ErrorCode.FAILED_PRECONDITION.equals(e.getErrorCode)) {
// cursor has expired, return appropriate error message
}
}
This works fine when manually testing against a long running spanner database. However, in my test code I create a spanner database and then tear it down once the test is complete and in these tests the spanner exception is only thrown intermittently when I use a read timestamp that should definitely be expired (say over a year old). In the cases where no exception is thrown, I get an empty resultset. If I make multiple requests to spanner in my test with this expired read timestamp, eventually the database seems to consistently throw the "failed precondition" error.
Is this behaviour expected for a newly provisioned spanner database?

Answer 1

I believe the reason for this behavior is because you are using Read-only Transactions. As explained in the documentation, Read-only transactions always observe a consistent state of the database and the transaction commit history at a chosen point. In your case, the database is created and torn down before and after your test is completed. Hence, no transaction commit history to be observed except after a number of attempts.