Проблема с управлением состоянием (PropertiesService) в Google App Script Chat Bot - PullRequest
Новая
       91

Проблема с управлением состоянием (PropertiesService) в Google App Script Chat Bot

0 голосов
/ 01 мая 2020

У меня есть бот чата Google Hangouts, реализованный с помощью Google App Script. Как и ожидалось, он в основном получает сообщение, обрабатывает его и отвечает. Я сохраняю состояние бота для данного пользователя, используя PropertiesService. Перед обработкой сообщения скрипт считывает предыдущее сохраненное состояние, использует его для обработки сообщения, обновляет состояние, сохраняет его и затем возвращает. 


var STORAGE_KEY = "my_bot_storage";

function onMessage(event) {

  let message = undefined;

  if (event && event.message) {
    message = event.message.argumentText;
  }

  var lock = LockService.getUserLock();

  var success = lock.tryLock(5000);

  if (!success) {
    console.warn('Could not obtain lock after 5 seconds.');
  }

  var userData = PropertiesService.getUserProperties().getProperty(STORAGE_KEY);

  botState = JSON.parse(userData);

  let bot = new Robot(botState);

  let response = bot.onMessage(message);

  var data = JSON.stringify(botState);

  PropertiesService.getUserProperties().setProperty(STORAGE_KEY, data);

  lock.releaseLock();

  return {
    "text": response
  }

}

function onAddToSpace(event) { // Does nothing }

function onRemoveFromSpace(event) { // Does nothing }

В дополнение к приведенному выше коду (Code.gs) у меня есть дополнительный скрипт, который определяет класс Robot с помощью простой функции onMessage, которая обрабатывает ввод и создает вывод - тестовая версия, где Я мог бы воспроизвести проблему, просто добавляет текст к исходному сообщению и отправляет результат обратно. Настройка basi c соответствует быстрому запуску .

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

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

Есть идеи о том, что может происходить?

...