Можно. А как его сформировать, а потом восстановить?

не уверен, что прям конечный вариант, но каждый этап диалога - элемент сета шагов (его-то мы можем сериализовать в json или таблицу) у каждого шага есть тип

еще как вариант использовать не сет, а вложенную структуру

{
 type: ask_song_title
 artist: Nirvana
 prev: {
   type: artist
   value: Nirvana
   prev: { … }
 }
}

upd. как будто предыдущий стейт нужен только в крайнем случае, когда есть необходимость назад идти и нет возможности из текущего достать данные

Неа, не надо назад идти. Достаточно хранить обычный набор ключ-значение, но надо ещё уметь продолжать с нужного места.

Нашёл первый недостающий ключ — задал вопрос.

продолжать - это как так?
вероятно, во время стартапа бот загрузить в память сессии пользователей (или при обращении пользователя к боту)
там же нет необходимости после шатдауна пинать пользователя, типа «э, слыш, мы там не все вопросики обкашляли»

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

Ну в голове я представляю общение линейно, вопрос-ответ.
А в коде будет большой свитч: нет такого-то ключа — задать такой вопрос, нет следующего ключа — другой вопрос и т. п.

да, примерно так же себе это представляю

sealed class Session {
 data class GetSongName(val artist: Artist) {
   fun handle(msg: Msg): Session = when {
     isValidSongName(msg) -> SearchForSong(artist, msg.text)
     else -> TODO(«hate this stupid user»)
 }
}

ну и дальше учишься сериализовать это в json и базу

ну а по поводу ключей и свитчей - это какой-то js-way же, хотя и так можно)
можно ли только полагаться на то, что наличие ключа artists где-то гарантирует, что ты до этого спрашивал артиста для поиска песни - хз, вроде не во всех случаях)

Можно, если точно известно, какой сейчас запущен сценарий, а ключи внутри одного сценария не пересекаются.

на всех ли этапах будут хоть какие-то ключи?)

Как закодить, так и будет)

вероятно, выбор теперь между:
{
 search_artist: Nirvana
 search_song_name: null
}
и:
{
 context: get_song_name
 object: {
   artist: Nirvana
 }
}
для сериализации куда-либо

У меня просто были сценарии как объекты. Был юзер в бд и у него было что-то типа current_scenario_id

Мб и глупо, но работало

Но это совсем абстрактно описал, конечно

Писал тоже на го

#android
Ситуация: в проекте у юзеров есть роли - флаги, по которым расширяется / ограничивается доступный функционал.
Сейчас они записываются в БД вместе с данными юзеров при логине и синхронизации. Проблема в том, что кое-где приложение тормозит с обработкой ролей.
Вопрос: как и где лучше хранить роли текущего юзера, если получать их требуется пачкой только при авторизации, а доступ к ним нужен по всему приложению? Нужно ли писать для этого дополнительные классы-обработчики?

Не знаю, можно ли мне отвечать, но попробую. Не думаю, что тут проблема в том где ты хранишь. У меня весь стейт приложения хранится в бд и постоянно сериализуется/десериализуется, при этом ничего не тормозит и не лагает, т.к. работа с бд моментальная. Тебе проще разобраться в причинах тормозов, чем сменить логику хранения, не факт, что станет лучше

Попробую разобраться с тормозами, спасибо.