queue1 и queue2 тебе точно нужны? можешь сделать одну очередь для обработки своих данных и все и обычно тут логика такая отправил в очередь и не ждешь результата обработки результат обработки может прийти не сразу и если он нужен то какойнить евент емитер должен его ловить например в совершенно другом месте
дело в том что у дочернего задания, есть тоже свое дочернее задание. Например - ребенок ребенка получает токен и передает его выше -> ребенок при помощи этого токена делать запрос, получает данные и передает выше -> родитель получает данные от ребенка, как то их обрабатывает и сохраняет в базу
Кажется, кто-то что-то заоверинженерил
в каждом задании идет обращение к внешнему api у которого ограничение на количество запросов, так бы я и правда все в одной задаче мог сделать и не городить кучу дочерних заданий
Из этого описания непонятно, зачем все эти "дочернее задание дочернего задания"
ну как, у меня есть 3+ запроса к внешнему api, я их разделил на дочерние задания, т.к. каждому выше стоящему ребенку нужен результат предыдущего
Зачем разделять на задания, если можно это сделать последовательно в одном задании?
может он не хочет чтобы когда фейлилось всё начиналось заного
Заново. Заново. Заново При последовательном выполнении точно так же можно повторять только зафейленные части
а как ты предлагаешь сделать последовательно в одном задании ?
Тебе нужно последовательно обратиться к нескольким эндпойнтам? for (const address of [1, 2, 3]) { const result = await call(address); }
ну это (отслеживать выполненные части задания) вроде как удобно ему показалось делать средствами bullmq через чилдрены эти как раз
получается что цикл выполняет в задании, а вот эта функция call, это подразумевается простая функция в которой я обращаюсь к api или это тоже отдельное задание ? Если это просто функция, тогда мне придется в ручную организовывать ограничение количество вызовов данной функции, а также повторы при неудачном обращении и прочие другие плюшки которые предоставляет bull. Тогда мне не понятно зачем вообще его использовать в данной реализации, если все будет написано самостоятельно. Если же это все такие отдельная задача, это ее результат выполнения я не получу в родительской задаче
Не использовал Булл, не знаю его возможностей. По его описанию всё звучит не очень, поэтому сделал выводы про оверинжениринг
Мне Булл в своё время понравился главное не оверинжинирить да
так все же есть варианты ка это можно сделать не через потоки ?
Чем то придется жертвовать
ну я так понимаю придется свою какую то реализацию кастылить )
Может не так страшно если будет запускаться заново вся таска при фейле
Обсуждают сегодня