Пункт назначения работает только тогда, когда Lambda вызывается через AWS CLI - PullRequest
1 голос
/ 30 января 2020

У меня есть тестовый мир Lambda, настроенный для:

  • триггер: API-шлюз
  • пункт назначения: Amazon SQS. одна очередь для успеха, а другая для неудачи.
import json

def lambda_handler(event, context):
    print("Received event: " + json.dumps(event))

    return {
        "statusCode": 200,
        "body": 'success'
    }

Когда я вызываю Lambda через CLI, сообщение помещается в очередь успеха, как и ожидалось:

aws lambda invoke --function-name event-destinations --invocation-type Event --payload '{}' response.json

Однако, когда я вызываю Lambda через шлюз API, никакие сообщения не помещаются в очередь ни в одну из целевых очередей. У меня включена интеграция с Lambda Proxy. Метрики Cloudwatch подтверждают, что вызов выполнен успешно (количество вызовов увеличивается, количество ошибок - нет). Следующее возвращает 200 и ожидаемое тело ответа из моего лямбда-кода:

curl 'https://REDACTED.execute-api.us-east-1.amazonaws.com/api_trigger' \
--header 'Content-Type: application/json' \
--data-raw '{}'

Аналогично, никакие сообщения не ставятся в очередь ни в одну из целевых очередей, когда я использую кнопку «Тест» на консоли Lambda. edit: это ожидаемое поведение для https://www.trek10.com/blog/lambda-destinations-what-we-learned-the-hard-way

Почему поведение назначения будет отличаться между этими 3 вызовами? Для этого теста я установил 0 попыток повтора.

1 Ответ

2 голосов
/ 30 января 2020

Кажется, есть набор допустимых пар {trigger, destination}, и {API Gateway, SQS} не является одной из них. Возможность вызвать лямбду из заданного триггера недостаточна для передачи события в пункт назначения. AWS консоль не применяет эти спаривания и не генерирует предупреждения.

Я ссылался на график из: https://www.trek10.com/blog/lambda-destinations-what-we-learned-the-hard-way/

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

...