Retry для блоков

[basvasilich]

Есть задача:
Если апи не ответило за 1 секунду — подождать 500мс и сделать перезапрос.
Если апи ответило и код ответа !== 200 — подождать 500мс и сделать перезапрос.
Если апи ответило с кодом 200, но в ответе есть поле errors и одно из значений этого поля backend.failed — подождать 500мс и сделать перезапрос.
Суммарно при обращении к каждой ручке апи делать не больше 3х перезапросов, если один из перезапросов закончился успешно — вернуть его ответ и прекратить перезапросы.

Как сделать перезапрос z понимаю. Как сделать его с таймаутом в 500мс нет.

Может надо сделать что-то типа option.retry ?

[chestozo]

Вот такая возможна конструкция:

de.Block.Delay = function(block, delay) {
    this.block = block;
    this.delay = delay;
};

no.inherit(de.Block.Delay, de.Block);

de.Block.Delay.prototype.run = function(params, context) {
    var promise = new no.Promise;
    setTimeout(function() {
        this.block
            .run(this.params, context)
            .pipe(promise);
    }.bind(this), this.delay);
    return promise;
};

Её можно добавить в sandbox

de.sandbox.delay = function(block, delay) {
    return new de.Block.Delay(block, delay);
};

и потом вызывать вот так:

de.delay(
    de.func(function() {
        return 1;
    }),
    1000
)

[pasaran]

Ну то есть нужно:

• Какой-то а-ля гвард, который определяет, когда нужно делать retry.
• Таймаут между ретраями.
• Число ретраев.

Т.е. как-то так:

de.block( ..., {
    timeout: 1000,
    retry_if: 'status != 200 || .errors.backend.failed',
    retry_timeout: 500,
    retry_count: 3
} )

Видимо, по-дефолту для блоков никаких ретраев быть не должно. Все должно быть задано явно. Потому что обычно ретрай это не очень хорошая идея. Т.е. признаком, что мы хотим ретраить будет retry_count > 0.

В retry_if лежит jpath, который вычисляется над результатом выполнения блока, плюс туда пропихиваются дополнительные переменные а-ля status (и что-то еще?). Тут начинаются проблемы, потому что status есть только у de.http.
retry_if опционален по идее, то есть если есть retry_count, но нет retry_if, то блок ретраится если он протаймаутился? Или еще по каким-то причинам?

retry_timeout по-дефолту равен 0.

Что еще?

[pasaran]

Да, таки непонятно, должно ли это быть у всех блоков или только у Block.Http?

[basvasilich]

Я применений кроме http пока не вижу.

в retry_if должен быть как и в guard доступен контекст, кроме того там была бы удобна функция c 'result, context' чтобы можно было посмотреть на результат, и принять решение

retry_if опционален, да ретраиться из-за тайаутов.

[pasaran]

Я применений кроме http пока не вижу.

С одной стороны, да. С другой — есть всякие составные блоки. Типа Block.Function или Block.Call или Block.Include, в которых тоже может быть что-то такое. Плюс сделать это для всех блоков, видимо, проще, чем только для Block.Http.

в retry_if должен быть как и в guard доступен контекст

Там проблема в том, что контекст он про входящий запрос главным образом. Например, там ничего нет про статус http-ответа или про заголовки http-ответа. Статус вообще плохо обобщается на другие блоки :(
Но в целом, кажется, что как раз контекст не нужен в этом месте. Тебе нужны только данные про конкретно этот запрос, точнее про ответ на него. Т.е. это результат и мета-информация: статус, может быть заголовки, ...

[chestozo]

Мне кажется, надо для всех блоков делать сразу.
Потому что можно будет и de.file перезапросить, если файл не удалось считать.

[pasaran]

Вот про файл интересно кстати. Там типа тоже есть своего рода статусы. Файл может быть просто не найден, тогда его не нужно перезапрашивать. А может быть какая-то другая ошибка, тогда, может быть и надо.
(хотя в целом, файловая система либо совсем сломана, либо же там все работает, перезапросы при чтении файла этот какой-то очень гипотетический случай).

[basvasilich]

Т.е. это результат и мета-информация: статус, может быть заголовки

Все так