в handler пропиши throw

но проблема не в этом

вообще ни разу

а не хуярить сразу реализацию

и все делайте так

все, кто пытается реализовать ретраи не расписывают задачу для себя достаточно подробно. И именно поэтому не видят всей сложности ретраев. Люди думают, что ретраи это просто. Но на деле в самой постановке задачи повторения запроса, есть очень много подводных камней. О которых люди просто не думают.

И эти подводные камни и вылезают, когда они пытаются реализовать

++++++++++

Это вообще про любую фичу так можно сказать :)

Если определить для себя, как именно нужно делать повторы, какие есть крайние случаи и как эти случаи решать, хотя бы просто на бумаге расписать алгоритм, то проблемы уйдут. Потому что проблемы реализации тупо в отсутствии понимания, что нужно сделать.

Эффектор подсвечивает эти проблемы, а не скрывает, как те же саги. Это значит, что нужно разобраться, что хочешь получить

просто обычные фичи слишком простые, чтобы их расписывать. И всё решение сразу же помещается в голове. Ретраи это не тот случай. И задача сама по себе сложная, даже без эффектора.

А когда не имеешь практики написания событийной системы в декларативном виде, то решить эту задачу становится ещё сложнее

Я могу даже список вопросов составить от которых зависит реализация

1. Независимые ретраи для каждого запроса или для всех сразу?
Независимо ретраить для каждого запроса:
- fx(1); fx(1); fx(2);
Если первый вызов fx(1) закончился фейлом всех ретраев, что делать? Отваливаться с fx.fail? Как будешь отличать какой именно вызов отвалился? Если нет, то как ты хочешь получить результат вызовов?

Мержить ретраи для вызовов с одинаковыми параметрами:
- fx(1); fx(1); fx(2);
второй вызов fx(1) не выполнит новый параллельный запрос.
Остальное как в первом примере

2. Каким образом решать когда ретраить, а когда нет?
- Если сервер вернул 400, ретраить далеко не всегда имеет смысл: если запрос невалиден из-за криво заполненной формы, зачем повторять десяток раз?
- Если сервер вернул 500, зачем ретраить много раз и дергать и без того упавший сервер? Не лучше ли увеличить время ожидания и попробовать лишь один раз?
- Если случился NetworkError, ретраить каждые 300мс когда нет соединения тоже нет смысла, нужно повторить запрос, когда соединение появится, а не бесполезно дергаться.
Но при этом, если запрос отвалился по таймауту, обработка вообще не может быть обобщенной и управление необходимо передать бизнес-логике, ведь если это создание, а операция не идемпотентна, то ретраи насоздают сотни сущностей. Но если идемпотентна, то всё будет ок, сервер просто вернет 400(и снова ретраить???)

3. Увеличивать ли время ожидания после каждого ретрая или нет?
- И вообще нужно ли время ожидания перед второй попыткой?
Ретрай имеет смысл, если мы получаем ошибку сети, но если увеличивать время ожидания после каждой ошибки(какой именно?) то получим, что через 5 ошибок, пользователь будет ждать слишком долго

4. Как отменять запросы?
- Если пользователь не хочет долго ждать ретраев, и нажал ОТМЕНА, с какой ошибкой возвращать управление в логику? Нужно четко прописать некую AbortError, с параметром retry_cancelled_by_user. Иначе обработка будет не корректной и отображение ошибок не будет показывать действительного хода обработки. В лучшем случае нужно показать "Вы отменили получение данных".

X. На самом деле вопросов ещё много, это те, которые я смог родить просто сходу. Вопросы будут появляться если начать думать над тем, что нужно получить от ретраев. Показывать ли прогресс и количество попыток пользователю? Хочет ли код реагировать на каждую ошибку в попытке запроса или только на общий результат?

да все просто
я хочу как в rx

мне эти вопросы даже не нужны

ну так юзай рх

и не доебывай сообщество

а зачем ммне выдумавать что то и постоянно менять ?

заебал

хаха