У нас есть ряд лямбда-функций, связанных с рядом очередей SQS. В основном это выглядит примерно так:
Lambda(foo) => Queue(Alpha) => Lambda(bar) => Queue(Beta) => Lambda(baz)
В этом случае Очередь (Альфа) является Пунктом назначения Lambda (foo) и источником событий для Lambda (bar).
Мы ожидаем, что Lambda (foo) успешно выполнится, затем передадим сообщение в Queue (Alpha), которое запускает Lambda (bar). Затем, если Lambda (bar) завершается успешно, он передает сообщение в Queue (Beta), которое запускает Lambda (baz).
В действительности, вызов Lambda (foo) отправит сообщение в Queue (Alpha) , который стреляет лямбда (бар); но затем обработка останавливается. Мы проверили логи, и все прошло успешно, но в очередь (бета-версия) не отправлено никаких сообщений. Чтобы исключить проблемы с разрешениями, мы вызвали Lambda (bar) напрямую, который отправляет сообщение в Queue (beta) и вызывает Lambda (baz), как мы надеемся.
Все целевые соединения настроены как асинхронные c. Тестовый вызов, который мы выполняли, выполняется следующим образом (например, при названии, поэтому можно игнорировать детали):
aws2 lambda invoke --function-name Queue(foo) --invocation-type Event --payload '{ \"input\": \"jphenow\" }' response.json
У кого-нибудь есть идеи, чего нам здесь не хватает? На момент установки все это асин c nodejs функций, которые выполняют context.callbackWaitsForEmptyEventLoop = false;
, но скоро они будут представлять собой смесь различных языков.
Явный вызов SQS также не исключен хотя не предпочтительнее, по крайней мере, для части нашей архитектуры.
Буду признателен за любую помощь или подсказки!
-
Обратите внимание, я нашел эту запись, но у них проблемы с первый пункт назначения работает, а не последующие очереди. Моя интуиция говорит, что это похоже на проблему, но я не могу сказать, как бы мне это дальше контролировать.