Там нагрузка копеешная...

у меня нагрузка - пара запросов в неделю )

Публичный у себя?

Да

Это для приватного. ) Для публичных самую "малость" побольше будет.

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

Он пока с демо девайсами. Подходит только поиграться... И пока скрипты без девайсов не работают...

Кого первого опубликуют...

Даже несколько тысяч обработать не сложно

Здравствуйте, я разрабатываю навык для Алисы на основе примера из документации(Python). Проблема такая, после того как навык был выложен в каталог(навык приватный), начались проблемы со словарем sessionStorage. Иногда получается так, что словарь перезаписывает свои значения, привязанные к ключу(user_id) или удаляет ключ вовсе(если в тестовом режиме пользователь напишет сообщение, то работа может быть продолжена. При этом ключ в sessionStorage либо вернесться к значения до удаления ключа, либо получит новые которых у него перед удалением ключа не было). Это происходит случайным образом, программа может отработать полностью правильно или вывести ошибку в самом начале работы навыка. Запросы "ping", от Алисы у меня отделяются на самом раннем этапе таким образом, чтобы  переменная sessionStorage не затрагивалась. Когда я решил запустить на прошедшем модерацию черновике навык из документации, выяснилось, что там таже ситуация. И там и там получается то, что теряется словарь sessionStorage, весь или его часть. Вот ссылка на этот пример: https://github.com/yandex/alice-skills/blob/master/python/buy-elephant/now/api.py.

колонка не разавторизуется автоматом по короткому таймауту?

через что вообще общаетесь с навыком? колонка или яндекс браузер с алисой? попробуйте и там и там

Вопрос к Админам, публичные навыки  умного дума планируется модерировать и публиковать, или вы их пока придерживаете ?

Я думаю, что проблема может быть в том, что для хранения данных user_id используется словарь sessionStorage в оперативной памяти экземпляра приложения.
Если приложение развернуто и настроено на использование нескольких копий (например в gunicorn кол-во workers > 1), то запросы от Алисы с одним user_id могут попадать на разные копии приложения.

Вариантов решения может быть два.

1. Настроить развернутое приложение на использование одной копии (плохо с т.з. производительности, но не требует изменений в коде)

2. Использовать для данных user_id общее для всех экземпляров приложения хранилище. Например, memcached или какую-то базу данных.

Спасибо за совет, сегодня ночью как раз реализовал запись и чтение данных из json файла. Вроде помогло, новых проблем не встретил.

Собственно, это второй вариант решения проблемы. Файл - общее хранилище для всех экземпляров приложения.

Вроде бы есть какой-то метод передачи информации между потоками как раз в gunicorn

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

мемкеш или бд все таки более надежно.

есть, но этот как раз организация глобального хранилища. по мне довольно извратный.

есть поидее еще вариант, настроить nginx на проксирование по user_id