About poller freq limitation

[tadelesh]

I found there exists a limit for the LRO polling interval. When I use the test proxy to do the scenario test, it will be hard to work around it for playback and cause the test duration too long. I know the way to handle it is to remove all the redundant polling tries in recording file, but it is not so convenient. I wonder this limit can be removed or any other better solution?

[jhendrixMSFT]

We set a floor to ensure that customers didn't accidentally specify too small a value and flood the endpoint with requests.

If this is problematic, the only solution is to write your own polling loop and not use PollUntilDone().

[seankane-msft]

@tadelesh can you provide a sample or PR for the issue you are seeing?

@jhendrixMSFT what is the floor for the time between requests? Can't we use the floor when we're in playback mode and otherwise use a more reasonable value?

[jhendrixMSFT]

The floor is one second and is baked into the internal poller type. I suppose we could detect if we're running a test and disable the check.

[seankane-msft]

poller := MyPoller{}
switch recording.GetRecordingMode() {
case recording.PlaybackMode:
        // manual polling
default:
        poller.PollUntilDone(...)
        ...
}

It's not the cleanest code, but this can be put into a function and re-used I think. We can also look at adding it to the internal package.

[jhendrixMSFT]

Good idea, and generics should make this reusable.

[tadelesh]

@jhendrixMSFT Thanks for the solution.
@seankane-msft The sample is here. For now, I need to add custom loop to handle response when playback. It can be abstract to a reusable func after generics support of poller.