Push Refresh : Allow users to update sync token from change events

[abhilasharora]

For the push refresh scenario, users can subscribe to key-value change events and invoke SetDirty method to ensure that the next call to RefreshAsync retrieves the updated configuration. This item tracks the addition of a way that allows users to provide the sync token received in the key-value change event, and ensures that the next refresh uses that token to receive the most-recent configuration, and avoids consistency issues due to replocation lag.

[zhenlan]

We probably should just pass the event to SetDirty and then let the sync token flow transparently to RefreshAsync, so users don't need to know about the sync token.

[abhilasharora]

Yes, that's the plan. I updated the title to clarify that we want to allow users to pass sync token, and don't need an additional API. Here's the change to the SetDirty method signature. We could also add multiple overloads, if needed.

void SetDirty(string? syncToken = null, TimeSpan? maxDelay = null);

[zhenlan]

Sounds good. Is it possible for the user to avoid parsing the sync token from the event?

[abhilasharora]

When using the Service Bus SDK to receive events, the user code would need to perform three steps. I don't see a clean way to avoid these steps in user code in a generic way.

1. Convert bye[] message.Body to a string
2. Parse the string as JSON to extract data -> syncToken
3. Pass the syncToken to SetDirty method

[zhenlan]

Yes, I understand users normally don't deal with events from the Event Grid directly. It really depends on which handler service they choose. Maybe we can take the whole JSON string or the data portion as the parameter.

I almost feel the sync token should be a required parameter. Without it, it relies on luck for the next refresh to fetch the latest change.

[abhilasharora]

Yes, we could take the whole JSON string as a parameter, assuming it conforms to our event schema across all handlers. When using Event Grid and Service Bus, here's an example of what sample code could look like.

serviceBusClient.RegisterMessageHandler(handler: (message, cancellationToken) =>
{
   string jsonEvent = Encoding.UTF8.GetString(message.Body);
   _refresher.SetDirty(jsonEvent);
   return Task.CompletedTask;
});

By default, we do have a randomized delay of up to 30 seconds before the SetDirty call would come into effect, which lowers the probability of missing the changes on next refresh. I do agree that making the sync token mandatory would help here, though it limits the use of SetDirty only to scenarios that respond to change events.