Груша, есть ли способ напрямую обратиться к данным внутри FSM

без функций?

Я имею ввиду state.storage.xxx...

Зачем?

Работаю со спамом, иногда у заблокированного юзера проскакивают сообщения хотя не должны. Полагаю дело в асинхронных запросах данных у фсм хранилища

Не факт, что дело в этом. Конкретнее в чём проявляется?

Какое хранилище?

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

Делаю это в самом конце схемы, возможно это тоже влияет, хз

Потому что надо делать без фсм. Только на питоне

Ага, и держать заблокированные айди в словаре, да?

^между переключениями уровней а как уровни переключаются?

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

Как вариант

не, я в плане именно реализации изменения данных по ключу статуса юзера в сторадже, нет ли там чего-то что может привести к этому поведению?

Этому поведению - о чем речь? Про то что сообщение проскакивает?

да если я правильно понял у тебя статусы переключаются как-то так?: no_warns, restricted_first_time has_one_warn blocked

Там число но смысл примерно такой, да

ну тогда по идеи сообщение может проскочить в то время когда у юзера снимаются ограничения и ещё не установлен статус blocked

Я тоже на это думал и оптимизировал как мог

не я о том что после того как у юзера заканчивается первое ограничение он же снова может писать в чат, верно?

Да. Я щас пытаюсь свой говнокод привести в красивый ООПшный вид чтобы я мог это упаковать в либу и использовать по кайфу

ну тогда логично что после этого могут проскочить сообщения пока ты его уже не заблокируешь навсегда.

Не скажи, там суть в том что обновление статуса происходит 1 раз. Если бы я мог заменить асинк чтение на синхронное, шанс проскока был бы в половину меньше

кратко: В препроцессе - lock.acquire(), в постпроцессе lock.release(), главное чтобы лок lock тот же был Ещё на это дам ссылку, вдруг когда пригодится подсмотреть чтото если надумаешь локи для юзера например брать https://github.com/darksidecat/aiopriman

Я не понял по описанию, чем ему не подошёл asyncio.lock

не понял вопрос

Я не понял по описанию, зачем он свои примитивы запилил

это я а не он)

Ой, это ты darksidecat?

Да ) А свои примитивы я делал для решения 2х проблем: хранение ключа по которому берётся лок и нормальный доступ к приватным проперти. Необходимость хранения ключа возможно стоит пересмотреть. Возможно в своих примитивах и нет необходимости, нужно подумать 🤔 А стоп, вспомнил) Ещё нужно хранить служебную информацию как здесь: https://github.com/darksidecat/aiopriman/blob/a3b08c79b3de76c1ca2d2b69a26559ffdd1ddd84/aiopriman/sync_primitives/semaphore.py#L27-L28 Вот что называется два месяца не заглядывал в репу

как оказалось я провтыкал и не установил username в телеге и он уже занят 😢

А если ты имел ввиду зачем вообще либа нужна то: Хотел упростить работу с локами в слудующих случаях: Допустим мне в одном месте для тролллинга нужно брать локи для юзера тогда я беру их для ключа "{user_id}:{"throttling"}" В нескольких других местах тоже нужен лок к некоторому ресурсу, тогда я в этих местах беру лок для ключа "somekey_name" и это будет один и тот же лок. Дальше, если лок не заблокирован и нет в очереди ожидающих то лок будет удалён с хранилища. Вот это я правда не тестировал на накладные расходы на создание/удаление и имеет ли это хоть какой-то значимый профит, нужно будет проверить кстати )

Интересно, спасибо)