Параллельное тестирование облачной функции DialogFlow

Question

У меня есть действие Google Assistant с выполнением через Firebase Cloud Functions. Я понимаю, что облачные функции могут совместно использовать экземпляры между вызовами, и что вы можете использовать глобальную область действия для выполнения тяжелой работы и подготовки. Моя функция создает глобальный класс, который сериализовал некоторые JSON и обрабатывает возврат данных и другие задачи в моей функции. У меня есть переменные в этом классе, которые устанавливаются при вызове функции, и я тщательно следил за тем, чтобы все переменные были установлены с использованием объекта данных сеанса conv.data, уникального для текущего разговора. Надежда состоит в том, что хотя экземпляр класса может существовать между различными вызовами и, возможно, разными пользователями, он все равно будет контекстуализирован в локальную область, и я не буду видеть какие-либо переменные, перезаписываемые другими сеансами.

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

Может кто-нибудь просветите меня, возможно ли выполнить два одинаковых действия с использованием одной и той же учетной записи пользователя? Выглядело, как будто объект conv.data имел смесь двух разных сессий, которые я выполнял, что говорит о том, что он использует один и тот же токен для обеих сессий.

Другой вопрос: как вы думаете, использовать глобальный класс? хранить состояние через вызовы будет проблемой для разных пользователей? Документы утверждают, что за один раз может произойти только один вызов функции. Так что не должно быть никаких сценариев с условиями гонки ios.

Answer 1

Поток диалога должен сохранять данные в conv.data изолированными для одного сеанса, даже сеансов от одного и того же пользователя. Когда вы используете Dialogflow, эти данные хранятся в контексте, который задает сеанс c.

Вы можете убедиться в этом, включив вход в систему StackDriver, что позволит вам изучить точный запрос и ответ, которые Dialogflow использует с вашим выполнением, и это будет включать идентификатор сеанса для отслеживания. (И если вы думаете, что они смешивают эти два, размещение деталей запроса и ответа поможет выяснить, что происходит.)

Очень грубо, похоже, что вы смешиваете что-то с вашим глобальным, или возможно, что-то установлено в одном сеансе, которое не очищается или не перезаписывается другим. Опять же - просмотр точных запросов и ответов должен помочь вам (и / или нам) понять это.

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

Конечно, я бы не использовал это глобальное состояние для хранения информации между сессиями. Хотя функция будет вызываться только, я не уверен, как это будет работать с Promises - что вам понадобится, как только вы начнете какие-либо операции asyn c. Кроме того, существует риск того, что последующие вызовы могут происходить в разных случаях.

Короче говоря, мой подход (который я делаю довольно устойчивым в мультивалюте):

• Сохранение всех состояний в Контекст (который conv.data должен делать так).
• Доступ к нему осуществляется через request, conv или через какой-либо другой объект c, определяемый запросом.
• Глобальная информация / конфигурация должна быть доступна только для чтения.