C # Polly async-await: дождитесь подтверждения пользователя перед повторной попыткой

Вы должны использовать .RetryForeverAsync(...), как заметил комментатор. Затем, поскольку ваш делегат при повторной попытке является асинхронным, вам также необходимо использовать onRetryAsync:. Таким образом:

.RetryForeverAsync(onRetryAsync: async (e,i) => await RefreshAuthorization());

Чтобы объяснить ошибки, которые вы видели: в примере кода в вопросе, используя onRetry:, вы указываете, что хотите использовать синхронный onRetry делегат (возвращающий void), но затем назначаете ему асинхронный делегат.

Это приводит к тому, что параметр async-delegate-assign-to-sync-param становится async void; вызывающий код не может / не может ждать этого. Поскольку делегат async void не ожидается, ваш выполненный делегат действительно будет непрерывно повторяться.

System.AggregateException: A Task's exception(s) were not observed может быть вызвано этим или может быть вызвано некоторым несоответствием в подписи myTask (недоступно в q на момент публикации этого ответа).

ИЗМЕНИТЬ в ответ на ОБНОВЛЕНИЕ на вопрос и дальнейшие комментарии:

Re:

Кажется, что RetryForeverAsync просто повторно генерирует старое исключение.

Я знаю (как автор / сопровождающий Polly), что Polly определенно вызывает переданный Func<Task<R>> каждый раз в цикле и будет только повторно генерировать любое исключение, которое выдает новое выполнение Func<Task<R>>. См. Реализацию каждый раз вокруг повторить цикл.

Вы можете попробовать что-то вроде следующей (временной, диагностической) поправки к своему вызывающему коду, чтобы увидеть, действительно ли RefreshAuthorization() теперь действительно блокирует продолжение выполнения кода политики вызова, пока он ожидает, пока пользователь нажмет «Повторить».

public class WebExceptionCatcher<T, R> where T : Task<R>
{      
    public async Task<R> runTask(Func<T> t)
    {
        int j = 0;
        Policy p = Policy.Handle<WebException>()
        .Or<MobileServiceInvalidOperationException>()
        .Or<HttpRequestException>()
        .RetryForeverAsync(onRetryAsync: async (e,i) => await RefreshAuthorization());

        return await p.ExecuteAsync<R>( async () => 
        {
            j++;
            if ((j % 5) == 0) Device.BeginInvokeOnMainThread(async () =>
            {
                 await DisplayAlert("Making retry "+ i, "whatever", "Ok");
            });
            await myTask;
        });
    }
}

Если RefreshAuthorization()) блокируется правильно, вам нужно будет пять раз закрыть Connection Lost всплывающее окно, прежде чем отобразится Making retry 5 диалоговое окно.

Если RefreshAuthorization()) не блокирует вызывающий код, политика продолжила бы выполнение нескольких (неудачных) попыток в фоновом режиме, прежде чем вы снова подключитесь и сначала закроете диалоговое окно Connection Lost. Если этот сценарий верен, то при однократном закрытии Connection Lost всплывающего окна вы увидите всплывающие окна Making retry 5, Making retry 10 (и т. Д., Возможно, больше) перед следующим Connection Lost всплывающим окном.

Использование этой (временной, диагностической) поправки также должно продемонстрировать, что Polly каждый раз заново выполняет переданный делегат. Если такие же исключения выбрасываются myTask, это может быть проблемой с myTask - возможно, нам нужно узнать об этом больше и копнуть глубже.

ОБНОВЛЕНИЕ в ответ на второе обновление создателя, начинающееся "Вот как я звоню runTask():"

Итак: вы предполагали, что повторные попытки заканчиваются неудачно, но вы создали код, который на самом деле не выполняет никаких повторных попыток.

Источником остающейся проблемы являются эти две строки:

Task<TodoItem> t = App.MobileService.GetTable<TodoItem>().LookupAsync(id);
TodoItem item = await catcher.runTask(() => t); // Or same effect: TodoItem item = await catcher.runTask(async () => await t);

Это всегда вызывает App.MobileService.GetTable<TodoItem>().LookupAsync(id) только один раз за обход этих строк кода, независимо от политики Polly (или в равной степени, если вы использовали ручной while или for цикл для повторных попыток).

Экземпляр Task не может быть повторно запущен: экземпляр Task может всегда представлять только одно выполнение. В этой строке:

Task<TodoItem> t = App.MobileService.GetTable<TodoItem>().LookupAsync(id);

вы вызываете LookupAsync(id) только один раз и назначаете t экземпляр Task, который представляет запущенный LookupAsync и (когда он завершается или дает сбой) результат этого одного выполнения. Во второй строке вы затем создаете лямбда () => t, которая всегда возвращает тот же экземпляр Task, представляющий это одно выполнение. (Значение t никогда не изменяется, и каждый раз, когда функция возвращает его, оно по-прежнему представляет результат первого и единственного выполнения LookupAsync(id).). Итак, если первый вызов завершился неудачей из-за отсутствия подключения к Интернету, все, что вы сделали для политики повторных попыток Polly, - это сохранить await-ing Task, представляющий этот первый и единственный сбой выполнения, поэтому исходный сбой действительно продолжает повторяться.

Чтобы проиллюстрировать проблему Task из картинки, это немного похоже на написание этого кода:

int i = 0;
int j = i++;
Func<int> myFunc = () => j;
for (k=0; k<5; k++) Console.Write(myFunc());

и ожидая, что он напечатает 12345, а не (то, что он напечатает, значение j пять раз) 11111.

Чтобы заставить его работать, просто:

TodoItem item = await catcher.runTask(() => App.MobileService.GetTable<TodoItem>().LookupAsync(id));

Затем каждый вызов лямбды будет вызывать .LookupAsync(id) заново, возвращая новый экземпляр Task<ToDoItem>, представляющий этот свежий вызов.