Выделенное место:

public Task ExecuteAsync(Func<CancellationToken, Task> operation, CancellationToken cancellationToken = new CancellationToken())
        {
            if (Suspended)
                return operation(cancellationToken);

            OnFirstExecution();
            return ExecuteImplementationAsync(ct => { operation(ct); return Task.FromResult(0); }, cancellationToken);
        }

Должно быть (иначе operation будет выполняться фоном и вызывающий код не увидит ошибок):

public Task ExecuteAsync(Func<CancellationToken, Task> operation, CancellationToken cancellationToken = new CancellationToken())
        {
            if (Suspended)
                return operation(cancellationToken);

            OnFirstExecution();
            return ExecuteImplementationAsync(async ct => { await operation(ct); return 0; }, cancellationToken);
        }

з.ы. ну и до кучи выскажу мнение, что не очень удобно (мягко говоря) работать с кидаемым RetryLimitExceededException и считаю его лишним. Работа с повторами должна быть прозрачной для вызывающего кода, тем более, что ее можно опционально включать/выключать в результате половину кода обработки исключений придется переписывать; и вообще не хотелось бы завязываться на такие "левые" с точки зрения БЛ исключения.

еще добавлю два момента:
1. в ShouldRetryOn часто важно знать attempt, а взять его неоткуда, т.к. текущее исключение добавляется в ExceptionsEncountered уже после вызова ShouldRetryOn
2. очень важно уметь в ShoudRetryOn/GetNextDelay различать ошибки вызванные connection.Open и command.Execute, т.к. от этого напрямую зависит логика/необходимость повторов, например для оракула:

2.1 connection timeout, session killed, все ошибки listener, ORA-12570 и т.п. — нужно повторять только во время connection.Open и бессмысленно во время command.Execute, т.к. тут поможет только полный реконнект.

2.2 в то же время ORA-04068, ORA-06550 — т.е. ошибки перекомпиленных/разваленных объектов БД вполне повторять можно в command.Execute.

с другой стороны непонятно как "кто" будет повторять логику переподключения, если session killed словили в command.Execute

поэтому DataConnection.RetryPolicy использую только для "софтовых" (2.2) ошибок, а для ошибок связанных с коннектом (2.1) приходится использовать Polly.


или я все неправильно "готовлю" и все задумывалось иначе и надо по-другому?