как обрабатывать лямбда-ошибки от шлюза API - PullRequest
0 голосов
/ 22 апреля 2020

Использование AWS Я настроил лямбда-функцию, используя Python, чтобы действовать как прокси. С помощью шлюза API я связал лямбду (с установленным флажком «Использовать интеграцию Lambda Proxy») со своим шлюзом API. Все работает нормально, за исключением того, что максимальный размер 6 Мб для лямбда-функции препятствует успешному возвращению моих больших файлов. Лямбда выводит сообщение об ошибке «Размер полезной нагрузки ответа превысил максимально допустимый размер полезной нагрузки. Function.ResponseSizeTooLarge», и шлюз API получает это сообщение от лямбды и печатает полученный ответ. Состояние 200 ',' Ошибка выполнения лямбды со статусом 200 из-за ошибки функции клиента: размер полезной нагрузки ответа превысил максимально допустимый размер полезной нагрузки ', а затем шлюз API выдает 502 с сообщением "Внутренняя ошибка сервера".

Я ожидал бы, что API-шлюз увидит это сообщение об ошибке и автоматически вернет слишком большой объект запроса 413, чтобы я мог реагировать на указанный c статус ошибки из моего веб-приложения.

В прошлом я мог использовать раздел Ответ интеграции на шлюзе API, чтобы найти это сообщение об ошибке и переопределить исходящий код состояния следующим образом:

#set($inputRoot = $input.path('$'))
$input.json("$")
#if($inputRoot.toString().contains("ResponseSizeTooLarge"))
#set($context.responseOverride.status = 413)
#end

К сожалению, потому что я Я использую эту лямбда-функцию из шлюза API в качестве лямбда-прокси. Я не могу использовать Integration Response для поиска этого указанного c сообщения и переопределения исходящего кода состояния.

Есть ли другой способ Я могу заставить шлюз API увидеть, что эти 200, которые он получает от лямбды, на самом деле имеют сообщение об ошибке и все равно должны быть 413? Единственный другой способ, которым я могу думать, это проверить размер полезной нагрузки от лямбды перед возвратом его в API-шлюз вручную, а затем изменив код состояния, прежде чем возвращать его, если он слишком велик. Я не хочу этого делать, потому что единственный способ получить байтовый размер объектов в python - это импортировать sys и использовать:

sys.getsizeof(lambdaResponse)

, и это, похоже, возвращает только размер ~ 258, хотя фактический размер его содержимого намного больше этого. Я также не хочу проверять размер каждой полезной нагрузки, потому что это, вероятно, добавляет ненужную задержку к ответам, которые не слишком велики для обработки.

Ответы [ 2 ]

0 голосов
/ 29 апреля 2020

так что, к сожалению, по умолчанию не существует способа справиться с этой ситуацией через шлюз API, все еще есть возможность обработать эту ошибку в лямбда-функции. Перед возвратом ответа от лямбды на шлюз api я воспользовался советом от man go и проверил размер ответа в байтах с помощью:

len(json_obj.encode("utf-8"))

, и если он превысил предел, который может использовать лямбда return я изменил response.status на 413 и изменил тело на сообщение об ошибке, объясняющее, что произошло

0 голосов
/ 22 апреля 2020

На данный момент нет способа достижения этого по умолчанию. Как вы уже сказали, лучшее, что вы можете сделать, это проверить размер полезной нагрузки, если сама лямбда, а затем исключение возврата / выброса.


Просто предложение, если ваш сценарий использования требует, чтобы полезная нагрузка ответа превышала разрешенный предел лямбда-функции, я бы посоветовал хранить полезную нагрузку ответа в некотором сегменте s3 и возвращать URL-адрес s3 полезной нагрузки в качестве ответа. Таким образом, ваше приложение будет хорошо масштабироваться при любом увеличении ответа. Более того, если эти ответы кэшируются, вы легко сможете повторно использовать тот же s3Url с небольшими изменениями в логике вашего приложения c.

...