Czy request będzie powtarzany:
jeśli nie udał się request (poleciał wyjątek podczas oczekiwania na odpowiedź,
albo odpowiedź jest inna niż oczekiwaliśmy),
albo content odpowiedzi zawiera string'a zawartego w config.RetryPolicyConfig.TriggeringMessage
Ile razy próbować powtarzać request:
tyle, ile jest zdefiniowane w config.RetryPolicyConfig.MaxAttempts
lub jeden raz, gdy tego config'a nie ma-
Jakie odstępy czasu pomiędzy próbami:
takie, jak zdefiniowano w config.RetryPolicyConfig?.Interval (w sekundach),
bądź 2 sekundy gdy brak config'a
Czy przebudować request przed następną próbą:
przebudować, gdy config.RetryPolicyConfig?.RebuildRequest == true,
lub gdy kod odpowiedzi HTTP wskazuje na nasz błąd (kod 4XX)
Przykład
dla danego banku mamy zdefiniowany retrypolicyconfig w ten sposób:
1{ "TriggeringMessage": "sample_triggering_message", 2 "Interval": 3600, 3 "MaxAttempts":3 4}
Strzelając o listę kont w tym banku przydarza się nam ten problem co w polish api, czyli ten access token wysyłany w header jest inny niż w body. Mechanizm powtarzania sprawdza czy odpowiedź zawiera "sample_triggering_message"
Jeżeli tak → próbujemy przebudować request a potem wysłać jeszcze raz, po
3600sekundach.Jeżeli nie, ale odpowiedź jest inna niż oczekiwaliśmy oraz kod odpowiedzi HTTP to 401 → próbujemy przebudować request a potem wysłać jeszcze raz, po
3600sekundach.
przykład 2
1"RetryPolicyConfig": { 2 "Interval": 2, 3 "MaxAttempts": 2, 4 "RebuildRequest": true, 5 "TriggeringMessage": "Authorization header is not equal Bearer + requestHeader.token" 6 },
Czyli jeżeli oni dsotaniemy response message: Authorization header is not equal Bearer + requestHeader.token
to powtórzymy go max 2 razy w odstępie 2 sekund
a rebuild true to znaczy że z bazy od nowa pobierzemy wartości tokenów etc.
jeśli byłoby false to strzelimy dokladnie tym samym co poprzednio