Устранение неполадок, связанных с лямбда-взаимодействием Amazon Alexa Skill Kit (ASK)

Начинаю с разработки ASK. Некоторое поведение меня немного смущает, и я хотел бы знать, как отлаживать ошибки из консоли "симулятора сервиса". Как я могу получить дополнительную информацию об ошибках The remote endpoint could not be called, or the response it returned was invalid.?

Вот моя ситуация:

У меня есть навык и три лямбда-функции (ARN: A, ARN: B, ARN: C). Если я устанавливаю конечную точку навыка на ARN: A и пытаюсь протестировать его с помощью симулятора службы навыка, я получаю ответ с ошибкой: The remote endpoint could not be called, or the response it returned was invalid. Я копирую лямбда-запрос, я направляюсь в лямбда-консоль для ARN: A, я даже устанавливаю тест , вставьте запрос из симулятора службы, я тестирую его и получаю отличный ответ ASK. Затем я перехожу к лямбда-консоли для ARN: B и создаю фиктивный обработчик, который возвращает точно такой же ответ, который ARN: A дал мне с консоли (буквально скопируйте и вставьте). Я установил конечную точку своего навыка на ARN: B, протестирую его с помощью симулятора службы и получаю ожидаемый ответ (поэтому ответ хорошо отформатирован), хотя и статический. Я снова перехожу к лямбда-консоли, копирую и вставляю код из ARN: A в новый ARN: C. Установите конечную точку навыка на ARN: C, и он отлично работает. Проблема с ARN: C заключается в том, что у него нет надлежащих разрешений для сохранения данных в DynamoDB (я все еще знакомлюсь с системой, не уверен, могу ли я разделить роль IAM между разными лямбдами, я думаю, что нет). Как я могу понять, что происходит с ARN: A? Это где-то записано? Я не могу найти ни одной записи в облачных наблюдателях / журналах, относящейся к этой конкретной лямбде или к навыку.

Не уверен, что это актуально, я использую python для своей среды выполнения лямбда, код (на данный момент) встроен в веб-редактор, и я использую boto3 для сохранения в DynamoDB.


person Josep Valls    schedule 11.08.2016    source источник
comment
К вашему сведению, мне удалось правильно настроить разрешения DynamoDB для ARN: 3, и все работает нормально с ARN: 3, по-прежнему не работает для ARN: 1, поэтому мне все еще интересно знать, как отлаживать / получать дополнительную информацию в таких случаях.   -  person Josep Valls    schedule 11.08.2016


Ответы (4)


tl; dr: The remote endpoint could not be called, or the response it returned was invalid. также означает, что ожидание конечной точки могло быть превышено.

Я смог сузить его до тайм-аута. Похоже, симулятор сервиса Alexa (и сама Alexa) менее терпим к длинным ответам, чем консоль лямбда-тестирования. Во время разработки я увеличил тайм-аут ARN: с 1 до 30 секунд (тогда как я считаю, что по умолчанию это 3 секунды). Таблица DynamoDB, используемая ARN: 1, содержит больше данных, и ее обработка занимает немного больше времени, чем ARN: 3 с почти пустой таблицей. Как только я закомментировал некоторые моменты загрузки данных, он стал работать немного быстрее, и симулятор службы Alexa снова заработал. Я нигде не могу найти задокументированный бюджет времени, полагаю, 3 секунды? Скорее всего, мне нужно перейти на другой бэкэнд, DynamoDB + Python на лямбде слишком медленный для очень тривиальных запросов.

person Josep Valls    schedule 11.08.2016
comment
Я попробовал Lambda + Java + DynamoDB и не смог заставить его работать в рамках бюджета времени. Я думал, что это 8 секунд, но из практических соображений я действительно не хочу, чтобы моим пользователям приходилось ждать более 3 секунд. Для StarLanes мне нужно было прочитать как минимум две записи и написать как минимум одну. Это высосало около 2 секунд из бюджета времени. Поскольку Lambda убивала JVM между вызовами, я не мог ничего кэшировать или фоновый поток. Поэтому сейчас я использую Lambda только в качестве прокси для веб-службы, где я могу выполнять любую оптимизацию, которую хочу. - person Joseph Jaquinta; 11.08.2016

Не связано с python, но я обнаружил, что такая же проблема возникает у меня, если у меня нет обработчика для указанного намерения:

  # lets pretend intentName is actually 'FooBarIntent'
  if (intentName == 'TestIntent') {
    handleTestRequest(intent, session, callback);
  } else {
    throw "Invalid intent"; 
  }

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

Вы также можете отключить лямбда-ошибки с помощью aws cloudwatch, который выявить любые предупреждения или ошибки.


ознакомьтесь с моим репо, alexa lambda starter kit, чтобы получить простой привет мир, спросите / лямбда-пример.

person lfender6445    schedule 29.03.2017

Я думаю, что проблема с ARN: 1 заключается в том, что вы, вероятно, не установили триггер для навыка alexa в своей лямбда-функции.

Или это может быть тайм-аут сеанса alexa, который по умолчанию установлен на 8 секунд.

person Dheeraj Suthar    schedule 31.08.2016
comment
Спасибо. Я уже сузил его до проблемы с таймаутом, откуда у вас тайм-аут 8 секунд? Я могу изменить крайний срок в лямбда-функции, чтобы не было тайм-аута, но у Alexa все равно тайм-аут. Я чувствую, что это значение немного меньше 8 секунд, и для уверенности я установил тайм-аут на 3 секунды. - person Josep Valls; 31.08.2016

Я предполагаю, что вы пропустили шаг при настройке. Там вы должны установить «источник события». ЕСЛИ вы этого не сделаете, я думаю, вы поймете это сообщение.

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

Из-за отсутствия параметров отладки лучше всего делать то, что вы сделали. Разделение и повторное тестирование. Делайте статические ответы, пока не поймете, в чем проблема.

person Joseph Jaquinta    schedule 11.08.2016
comment
Спасибо за ответ, обязательно посмотрю на EchoSim. Некоторые параметры отладки и более подробные сообщения были бы замечательными. - person Josep Valls; 11.08.2016