Blob Change-Feed Continuation Token is not working as expected

Papajohn, April 101 Reputation points
2021-04-09T18:06:57.567+00:00

I am using the Java SDK to get blob-modification updates, and I am seeing surprising behavior from the continuationToken. I am storing the continuationToken from the last page of results and using that stored token for my next request, i.e.:

  1. String theCheckpoint = page.getContinuationToken();
  2. Wait a while, modify some blobs in the meantime
  3. results = blobChangefeedClient.getEvents(theCheckpoint);

results will be empty. I would expect results to contain the records of the blob-modifications I did.

The problem seems to be the EndTime field that is in the token, because if I take that token and manually modify the EndTime to be one day out, then the token works as desired and I get back the events that happened.

The question is: why doesn't the blob-change-feed request detect the latest changes when I pass it the continuation token?

After further exploration, I think I can narrow down the problem.
At 15:15 on April 9th, I requested the events from the change feed, passing a blank for a continuation-token. I got this back:
{"CursorVersion":1,"UrlHost":"zuse1hltd1lexists.blob.core.windows.net","EndTime":"2021-04-09T15:00:00Z","CurrentSegmentCursor":{"ShardCursors":[{"CurrentChunkPath":"log/00/2021/04/08/1700/00000.avro","BlockOffset":3054,"EventIndex":0}],"CurrentShardPath":"log/00/2021/04/08/1700/","SegmentPath":"idx/segments/2021/04/08/1700/meta.json"}}

The EndTime seems to render this cursor unusable. In order to make it usable, I have to manually modify the EndTime.

Azure Blob Storage
Azure Blob Storage
An Azure service that stores unstructured data in the cloud as blobs.
2,415 questions
{count} votes

2 answers

Sort by: Most helpful
  1. shiva patpi 13,131 Reputation points Microsoft Employee
    2021-04-13T05:59:58.403+00:00

    Hello @Papajohn, April ,
    Thanks for your query ! It seems this issue is some what similar to the one reported here in git hub. Kindly have a look at it.

    Above issue was reported for NodeJS and I guess it is applicable for Java SDK also as the underlying API will be the same.

    Root cause was mentioned as "The SDK returns continuation token with "EndTime": null, when it's returned in the second page, which is because converting a null string to an invalid date object in code"

    Let us know if the above helps you out in understanding the issue.


  2. Papajohn, April 101 Reputation points
    2021-04-13T18:51:11.317+00:00

    I discovered the answer. the EndTime field in the continuation token reflects the end time passed in to the client.getEvents call. So it is necessary for the first call to be either:
    client.getEvents()
    or
    client.getEvents(startTime,null) in order to get a usable cursor token back.

    0 comments No comments