Tosd
Tosd
+1 同样出现类似情况。无法正常推送动态，每10s(HARUKA_INTERVAL)报错一次。
> 应该是这个接口有限流操作 刚才那个只是临时解决 发现部署在服务器上 超过一定的请求就会这样 > > 经过测试 加大`HARUKA_DYNAMIC_INTERVAL`的时间以及修改之前的metadata入参可以避免反复写日志 应该是同一个时间段不能多次请求这个接口 写-352日志的间隔时间=HARUKA_DYNAMIC_INTERVAL设置的时间 ~~如果只加大HARUKA_DYNAMIC_INTERVAL（我设置成60）也无法避免-352且无法正常推送动态。只是让它变成了60秒报错一次而已~~ ~~如果同时修改，仍然无法正常推送动态，只是后台不报错了。（我连续发了四条动态一条也没推送）~~ ~~静待下一步解决策略（~~ 实际上两者均操作确实避免了日志刷屏和动态推送问题不过需要挂一段时间
> 他用了一个很奇怪的设计,就是他的最近一条动态信息是保存在内存的不是持久化的在`sqlite`中的 也就是当你初次启动的时候它需要几次同步来加载你最近一次的最新动态信息(这个取决于你关注的人个数 > > 也就是你需要等它将你的记录到内存中之后再发动态才会触发下面这段 > > 大概就是等待你的HARUKA_DYNAMIC_INTERVAL*(你的关注人数+1)初始化好了， 之后就是你发完新动态之后等待HARUKA_DYNAMIC_INTERVAL*(你的关注人数) 它就会提示到新动态了 (说实话，这个动态爬取竟然不是一起爬的 而是每次执行` uid = await db.next_uid("dynamic")` 遍历的很奇怪) 原来是如此的机理……我后来没管它 它也开始自己推送了我甚至都没反应过来，这个方法确实有效果我去改一下上面的评论（）
> 确实不352了 (悄悄的问下需要挂多长时间才能继续推送) 上面noahlias说过是HARUKA_DYNAMIC_INTERVAL*(你的关注人数+1)秒钟。
> 改ua的办法已经无效了（ 现在的解决方法是按照这个PR自行修改site-packages 中的bilireq库 https://github.com/SK-415/bilireq/pull/26/files
> 我修改了bilireq库之后还是会报错 尝试增加HARUKA_DYNAMIC_INTERVAL呢？报错仍然是-352吗
> 目前主动发言阈值是分群的，难道是群太多了，一个一个设比较麻烦吗？ 是的，大部分群不想让机器人说话，就想让小部分愿意让机器人说话的开（ 而且新加的群默认也都是5，每次都要更新的话确实麻烦 如果能添加一个修改默认值的配置就好了（ 编：下意识点成了close（？
> 如果你指的刷新是修改 `.env` 文件中的设置，在目前的配置逻辑下是无法实现的 那能否使用手动命令给机器人发session token让他刷新呢，可以覆盖.env文件里的那种
出现了同样的问题🥲可以用这个办法绕过我设置的全局000的权限。个人认为可以设置全局默认权限和强制权限，即全局默认权限设置为未设置分群配置下的默认权限，而全局强制权限为忽略分群配置的权限。并且设置全局强制权限为手动给特定开启