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

Я реализую свой собственный сервис webhooks, который будет отправлять события подписанным webhooks.

Обзор архитектуры:

  • события помещаются в очередь SQS
  • лямбда-функция запускается сообщениями SQS (сопоставление источника события)
  • для каждого события, я выполняю исходящие http-запросы к подписанным веб-заездам
  • не-2xx ответы должны быть повторены с экспоненциальным откатом ( в таком случае я изменяю видимость сообщения в полученном сообщении)
  • , поскольку лямбды, которые вызываются SQS, автоматически удаляют сообщение по завершении, я выкидываю сообщение об ошибке в конце функции, чтобы предотвратить автомат c delete

Насколько я могу судить, вызов для изменения видимости сообщения завершается успешно. Мне интересно, есть ли что-то еще запеченное в лямбдах, которые вызываются SQS. После отказа от лямбды, это внутренне изменяет видимость сообщения снова? Или же лямбды, которые вызываются SQS, не учитывают изменения видимости сообщений (для меня это не имеет никакого смысла). Любопытно, если у кого-нибудь есть понимание этой проблемы. Я был очень удивлен, обнаружив, что лямбда автоматически удаляет сообщения при успешном завершении, поскольку это делает мой конкретный случай использования немного неуклюжим - выдает ошибку, чтобы не выполнить функцию лямбда, чтобы предотвратить удаление сообщения.

Спасибо заблаговременно!

Ответы [ 2 ]

1 голос
/ 24 февраля 2020

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

0 голосов
/ 20 марта 2020

Обновление: на самом деле это не так. Мне не удалось должным образом дождаться звонка, чтобы установить таймаут на окончание sh. Таким образом, лямбда закрывалась до завершения этого запроса. Время ожидания, которое я устанавливаю для сообщения в лямбде, соблюдается. Затем я выдаю ошибку, чтобы предотвратить удаление сообщения.

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