AWS Лямбда с триггером SQS, Лямбда-адресаты SQS, никогда не добавляются в очередь назначения - PullRequest
0 голосов
/ 09 января 2020

У меня есть простая лямбда-функция, которая запускается из очереди SQS, и я использую новую функцию Лямбда-адресаты .

Она настроена на запуск с QUEUE_A, выполните некоторые модификации тела полезной нагрузки, а затем отправьте его по адресу QUEUE_B при success или QUEUE_ERRORS при fail .

QUEUE_B и QUEUE_ERRORS установлены как Направления в функции лямбда-функции.

Когда я запускаю лямбду из CLI, я получаю запись о QUEUE_B с хорошей записью и QUEUE_ERRORS с плохой записью. Так что, похоже, работает.

Но, когда лямбда запускается из SQS, я никогда не получаю запись о QUEUE_B или QUEUE_ERRORS. Хорошая запись запускает лямбду, а на плохой записи - QUEUE_A_DEADLETTER, что мне не нужно.

Я попытался настроить QUEUE_A, чтобы не было повторов / тупиков - если я это сделаю, на плохой записи он будет повторяться вечно (независимо от того, насколько низко я установил видимость / повторы).

Что я могу попробовать дальше?


РЕДАКТИРОВАТЬ :
CloudWatch показывает мне именно то, что я ожидаю увидеть - я вижу хорошие журналы на «хорошей» записи и складываю трассы / исключения на «плохих» записях, так что это не проблема внутри самой функции AFAIK.


РЕДАКТИРОВАТЬ : замена триггеров и назначений SQS на триггеры и назначения SNS работают. Итак, я думаю, это связано с тем, что SQS является syn c, а SNS - asyn c? Кто-нибудь знает?

enter image description here

1 Ответ

1 голос
/ 10 января 2020

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

Основной вариант использования Destination - это знать о асинхронных c результатах выполнения функций Lambda, прежде всего, чтобы лучше понять детали выполнения, такие как контексты запроса и ответа, полезные данные, трассировки стека исключений и т. д. c. Поэтому, если лямбда была вызвана синхронно (скажем, с помощью cli или через триггер SQS), никакие сообщения не будут доставляться конечным точкам назначения.

Когда вы использовали CLI, вы бы использовали aws lambda invoke-async. Вместо этого, если вы используете aws lambda invoke (который выполняет Lambda синхронно), вы увидите те же проблемы, конечные точки назначения не получат сообщение.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...