循环卡死在重新创建订单的阶段，以及python多开账号的问题

[CinnabarCHU]

Checklist: 问题在同一设备上可以稳定复现；检查了Discussions和Issues未发现同类问题。
Configuration: MacOS Ventura, Python 3.11.7, venv activated, pip3 install -r ./requirements.txt.
Background: 命令行运行，账号多开，不同账号使用不同的源代码拷贝及虚拟环境，但同一账号的不同进程使用同一份拷贝。

目前的情况是抢票任务的循环会在某次tab.go:start_go:366( - 请求错误: 重试次数过多，重新准备订单)后直接卡死，新的订单和token不会创建，直至手动停止抢票后重启抢票。这个问题在单一账号仅仅开一个进程时出现较少，但是在单一账号进程多开时出现频率显著增加，目前没有发现不同账号之间对这个现象存在干扰。
检查了log的输出，和控制台输出一致，某个进程的输出在最后报出ERROR提示tab.go:start_go:366后就直接消失了……人目前手上设备就是台笔记本电脑，环境配的不是很全导致debug有些困难，甚至现在连点头绪都没有，就没好意思提Issue，姑且先扔到Discussions里蹲一个有缘人，今晚忙完我可能会看看，但是以我的水平估计是很难找很快出来。 X(

此外，使用Python多开的话，登陆逻辑存在Cookie问题，具体表现是如果不预先准备好Cookie而是使用Edge来登陆，即使使用不同的虚拟环境与源代码拷贝，只要在一个实例上登出账号，所有的实例的登录状态似乎都被扬了，此时再用Edge登陆采集cookie，所有的实例又会集体开始使用采集到的新cookie……我对这个更是一点头绪也没有，虽然尝试后发现确实可以复现，但复现不稳定，且由于这块程序的逻辑相对更复杂（加上我在多次登陆我的大会员估计危……），我没有做进一步的尝试，解决方法就是先准备好cookie然后直接配置tmp文件夹。而且看别人也多开了，估计Windows的分发版没这个问题（反正能用就行，不需要自己去扒逻辑写代码已经很好了555，谢谢贡献者们（鞠躬）

一点实验的尝试作为符合Discussions发言的补充（我真不是故意不提Issue的……）：

1. 频率过高大概率封IP，我IP被封时的设置为100 ms * 5，但是被封了不要慌，能上github给自己全局换个IP应该不难吧（反正当时也已经是蹲回流票了……）
2. 提前15 s依然喜提账号异常，前面那个10 s的哥们我只能说艺高人胆大……
3. 真运气不好该抢不到还是抢不到，毕竟算法摆在那里，唉，二次元的一生都在和奖池打交道，我是哪个大洲的人我还不清楚吗55555

PS 因为阿B去年的网页端逻辑可以卡时间差蹲回流票，加上以前的退票真就直接回流处理了，一直到凌晨都有回流票，因此之前一直是手抢仙人，结果今年翻大车……至今还是一张没抢到。今晚的开票本来想试一下脚本，手上现在可用的二级以上账号不够多（其实只有两个半），运气不好还是一张没有，希望明天能顺利，多少能去一天吧，唉……

[mikumifa]

cookie那点地方确实要改

[CinnabarCHU]

把cookie那块看了看，大概对发生了什么有个猜测，但是还是没有想明白为什么拷贝了多份源代码，在不同目录下运行还是会发生一样的问题……又来了一个活，可能过一会做完再看看，我感觉cookie那边问题不大，绝大多数人没有我这样的需求，我估计改起来要费很多精力，如果贡献们精力有限完全可以搁置，现在的逻辑足够用了……再次感谢大大的项目，让我这个手残（指抢票）又手慢（指码代码）的人能还有点盼头55555

[CinnabarCHU]

卡死的问题忙完看了看还是没有任何头绪，./tab/go.py Line 366 处理HTTPError的逻辑没看出来有问题，这个异常只能被Line 317扔出来但inner_request()的逻辑看起来也没有任何问题，但是为什么回不到准备订单的逻辑去呢……

[mikumifa]

感觉要打断点进去看

[gpc123456]

我觉得您定位的点应该是正确的，确实可能是post请求没有添加timeout参数导致无限等待。不过结合具体的业务逻辑，我认为只需要在 BiliRequest.py 中给相应的get和post请求添加延时即可，理由如下：

• inner_request()中发送post请求的url: https://show.bilibili.com/api/ticket/order/createV2? 为通过验证码后拿到用户token后提交订单的接口，对应APP中进入付款页面一直点提交订单的过程。在这个过程中，已有 @retry.retry(exceptions=RequestException, tries=60, delay=interval / 1000) 捕获超时错误并重试。这个阶段要确保错误不能被抢票过程中的大错误捕获所捕捉，因为这样会重新进入订单准备阶段浪费时间，这点脚本已经考虑到了。
• 在其他阶段，RequestException并不会影响程序正常运行，因为他们均会被抢票过程中的大错误捕获所捕捉，进入下一个循环，重新进入订单准备阶段，也不会引发程序中断。而且这些阶段重新进入循环并不会影响抢票时效性，我为没有必要添加重试，直接超时引发错误重开就行。您可能想问：抢票成功后，获取付款二维码的get请求超时会不会对抢票有影响呢？我认为几乎没有影响，因为只要https://show.bilibili.com/api/ticket/order/createV2? 的 post 请求能够成功提交，在APP的待付款订单中就可以看到这份订单并进行付款，至于WebUI中是否显示付款码则影响不大。

综上所述，我认为您直接在BiliRequest.py 中给相应的get和post请求添加延时，即可满足程序的正常运行需求，解决脚本卡死的问题，并最小化对原始抢票逻辑的影响。

Edit：
您直接在您的Fork的基础上，将相应的timeout值调小一些我觉得就可以(^_^)

[gpc123456]

刚刚看到您的更新，按照上面所说，我觉得只有 https://show.bilibili.com/api/ticket/order/createV2? 这个接口的post请求需要重试，其他的接口没有反复重试的需求，所以不需要在BiliRequest类的post()和get()方法中单独捕获requests.exceptions.Timeout异常反复重试直到不出现timeout为止，这样有点浪费时间，直接让他们抛出错误即可，使用 ‘start_go’ 函数中的抢票流程全局try捕获后，重新开始订单流程即可，这样也可以同时避免因反复重试后，token过期导致请求出现问题。

[CinnabarCHU]

Edit： 您直接在您的Fork的基础上，将相应的timeout值调小一些我觉得就可以(^^_)

感谢您的建议，在您建议的基础上，我检查了整个程序中其他功能模块的业务逻辑，直接扔出requests.exceptions.Timeout唯一的风险点在于./tab/train.py没有全局的try捕获，如果在Train Tab发生Timeout异常可能会掷穿整个程序（我对gradio不了解不知道这个包是否有其他的异常补救措施），所以我可能会在改动BiliRequest.py 的同时对train.py的异常处理稍作改动。我十分赞同您关于timeout时间设置的建议，我考虑了一下抢票的实际场景，超过1 s的响应除非在海外否则非常罕见，即时有舍去也未尝不可，尽可能高频率地提交请求大抵还是关键，所以最后我应该会将get()和post()方法的timeout设置为1 s，再次感谢您的帮助！

[gpc123456]

感谢您的耐心阅读与回复！据我所知，gradio在使用组件提供的输入与输出机制时是带有错误保护的，不会戳穿整个程序，这点您可以放心。通过手动断开网络连接来模拟请求超时的场景也可以验证这一点(如下图所示)，因此我觉得在./tab/train.py无需再手动加入错误捕获。

[CinnabarCHU]

由衷感谢您的信息，如此我就无需改动./tab/trian.py了。根据您的建议，我在最终提交的Pull Request将timeout设置为1 s，此配置刚刚在我目前所在的网络环境中测试，基本没有出现请求timeout的情况，最终的timeout设置交由维护者决定。

[SouthSeafireworks]

我提前1分钟抢，程序也显示账号异常，但到时间不影响抢票，你那里是啥提示

[CinnabarCHU]

我是提示异常后一直显示HTTP 412，被ban大约10 min左右……

[weiyusheng]

关于python账号多开的那个问题，会不会是拷贝代码的时候把数据库里的文件连带cookie_path属性也复制过去，导致其实几个实例用的是同一份cookie文件？
如果是这个原因，清掉tmp再拷贝就能解决（大概）。
另外建议给一个重置cookie_path和cookie的选项，直接作用于DB的那种。
@CinnabarCHU