Я включил потоки в своей таблице DynamoDB. При изменении элементов запускается лямбда-функция. Думаю, я правильно все настроил и на стороне лямбда-триггера, и на разрешениях, и на стороне Dynamodb. Я также запустил свою лямбда-функцию с тестовыми данными, и это удалось. Однако при изменении элементов в таблице триггер не запускал мою лямбда-функцию. Вместо этого я получил следующую ошибку:
Размер пакета: 100 Последний результат обработки: ПРОБЛЕМА: сбой при вызове функции
Есть идеи, как лучше всего отладить это? Я зашел в журналы CloudWatch, но не было журналов, связанных с триггером / потоком.
Спасибо.
Обновлено: журналы лямбда-функции (а не ее триггера Dynamodb). Триггер не генерировал никаких операторов журнала.
START RequestId: 3a08eedc-f0de-11e8-9008-033b48d2cb67 Версия: $ LATEST 18:16:28 END RequestId: 3a08eedc-f0de-11e8-9008-033b48d2cb67 18:16:28 REPORT RequestId: 3a08eedc-f0de-11e8-9008-033b48d2cb67 Продолжительность: 81,85 мс Длительность выставления счета: 100 мс Размер памяти: 128 МБ Максимально используемая память: 30 МБ
В1: я увидел это сообщение, когда щелкнул триггер Dynamodb в лямбда-консоли. Q2: На самом деле я не думаю, что настраивал журналы с триггером. Как настроить журналы для триггера? Спасибо.
@ItayMaman, я обновил пост, добавив записи журнала. Оперативная память 128 МБ.
можешь поделиться кодом лямбды?
Так вы думаете, что проблема в коде? Мне сложно поделиться, так как код длинный (~ 150 строк). Если вы действительно хотите взглянуть, вы можете дать мне свой адрес электронной почты, и я могу отправить его вам. Но также, что было бы проще, если бы вы могли просто сообщить мне, каковы возможные причины этого, я смогу отладить себя. Спасибо.
Или LinkedIn тоже работает, если электронная почта неудобна.
На самом деле, поскольку вы подразумевали, что это проблема кода, мне пришло в голову попытаться отладить свой код. Поскольку я упростил свой код, сработал триггер. Так что я думаю, что это действительно проблема кода. Буду еще отлаживать.
Здорово! Очень рад это слышать :)
Я думаю, что проблема связана с циклами while, элементами пакета и сканированием. Я подумал либо о том, чтобы сделать рекурсию, как вы сказали, либо использовать async / await. Но для первого я не знаю, вызовет ли стек рекурсии другие проблемы. А для последнего это кажется действительно не интуитивным. Другая проблема - aws.documentClient в node.js использует обратные вызовы вместо обещаний. Поэтому для простоты я перехожу на Java. У Java и Python нет проблем с асинхронностью, которые есть в javascript / node.js.





Это звучит как возможный вариант использования Rookout, если вам нужно следить за значениями переменных в вашей живой лямбде в ситуации, когда вы не можете создавать журналы. и, запускающий его локально, не даст вам реальных данных триггеров событий. .
Я столкнулся с этой проблемой сегодня.
Test в верхней части основной лямбда-страницы. Он показал вывод ошибки при попытке запустить мою лямбду.handler, поскольку у меня было нестандартное имя функции javascript, и я забыл настроить его в своей лямбде.В моем случае у моей лямбда-роли не было разрешений на запись в SNS, а лямбда-код выполнял запись в SNS. Поэтому я добавил политику к лямбда-роли, дающую ей разрешение на запись в любую тему SNS.
Q1: где вы видели «Размер пакета: 100 Последний результат обработки: ПРОБЛЕМА: сбой при вызове функции»? Q2: что значит «нет логов, связанных с триггером / потоком». значит? где вообще есть журналы лямбды (хоть и не связанные с триггером / потоком)? Если бы были, можете ли вы их опубликовать? Q3: Вызывается ли эта лямбда другим источником событий? Q4: Сколько оперативной памяти выделено для этой лямбды?