FR: 支持绕过 高负载时Regenerate Response按钮被禁用 的功能

[CyanChanges]

最近ChatGPT经常遇到high demand，导致无法直接Regenerate Response。
能否实现在加载模块后，绕过high demand高需求限制，正常使用Regenerate Response功能？

[CyanChanges]

最近官方的会话管理会不定时高负载然后就寄了，所以还是建议恢复三方会话管理

[CyanChanges]

@bigemon

[bigemon]

我认为我们需要构建一些简单测试。
用于了解遭遇high demand时，ChatGPT的官方会话管理还有哪些接口可以正常工作。

毕竟：如果问题在于high demand 时 API被阻断，那么本地的会话ID管理可能不会有太大的作用。

如果对话相关的接口还能正常工作，那我们应该可以通过第三方会话管理暂时规避这个问题。
在下一次high demand状态的时候，我会尝试构建一些简单的验证确定问题。感谢反馈。

[CyanChanges]

我认为我们需要构建一些简单测试。 用于了解遭遇high demand时，ChatGPT的官方会话管理还有哪些接口可以正常工作。

毕竟：如果问题在于high demand 时 API被阻断，那么本地的会话ID管理可能不会有太大的作用。

如果对话相关的接口还能正常工作，那我们应该可以通过第三方会话管理暂时规避这个问题。 在下一次high demand状态的时候，我会尝试构建一些简单的验证确定问题。感谢反馈。

现在就high demand. @bigemon

[Eternity231]

可能已经在做了

[CyanChanges]

可能已经在做了

不到啊，这个high demand十分不稳定啊

[bigemon]

我认为我们需要构建一些简单测试。 用于了解遭遇high demand时，ChatGPT的官方会话管理还有哪些接口可以正常工作。
毕竟：如果问题在于high demand 时 API被阻断，那么本地的会话ID管理可能不会有太大的作用。
如果对话相关的接口还能正常工作，那我们应该可以通过第三方会话管理暂时规避这个问题。 在下一次high demand状态的时候，我会尝试构建一些简单的验证确定问题。感谢反馈。

现在就high demand. @bigemon

关于本地会话管理：

一个不幸的消息是，尝试附加多个旧的会话ID时，服务器都抛出了404。
这可能意味着，high demand状态时，backend-api/conversation 接口的id检索范围从后端进行了硬性限制。而不是因为高负载导致无法加载。

关于Regenerate Response 按钮失效：

另外，Regenerate Response 按钮失效一般出现在什么情况?
在我构建的测试中暂时没发现。

已复现。
这看起来似乎是一个官方前端的错误，只会在high demand状态弹出黄色警告信息时发生。
通过上一句对话的edit功能，可以正常的重新生成。而Regenerate Response功能实际上只是一个快捷按钮，和手动点上一句发言的edit没有区别。

通过一些简单的状态patch应该可以暂时屏蔽这个错误。

[bigemon]

经过一些简单的构建。Regenerate Response按钮现在即便在High demand状态也可以正常工作。
稍后将并入生成脚本内。

PS: 这个限制最终被发现来自于 页面初始化时的一个 "serviceStatus.oof" 属性。
一旦这个flag被设置为ture，那么Regenerate Response按钮就会被隐藏。
由于这个功能本质上只是一个快捷按钮，我不太明白官方前端隐藏它的用意。
也许是为了避免误触Regenerate Response导致的额外负载？

[bigemon]

仓库内的脚本已加入这个特性。

[CyanChanges]

我认为我们需要构建一些简单测试。 用于了解遭遇high demand时，ChatGPT的官方会话管理还有哪些接口可以正常工作。
毕竟：如果问题在于high demand 时 API被阻断，那么本地的会话ID管理可能不会有太大的作用。
如果对话相关的接口还能正常工作，那我们应该可以通过第三方会话管理暂时规避这个问题。 在下一次high demand状态的时候，我会尝试构建一些简单的验证确定问题。感谢反馈。

现在就high demand. @bigemon

关于本地会话管理：

一个不幸的消息是，尝试附加多个旧的会话ID时，服务器都抛出了404。 这可能意味着，high demand状态时，backend-api/conversation 接口的id检索范围从后端进行了硬性限制。而不是因为高负载导致无法加载。

关于Regenerate Response 按钮失效：

另外，Regenerate Response 按钮失效一般出现在什么情况? 在我构建的测试中暂时没发现。

已复现。 这看起来似乎是一个官方前端的错误，只会在high demand状态弹出黄色警告信息时发生。 通过上一句对话的edit功能，可以正常的重新生成。而Regenerate Response功能实际上只是一个快捷按钮，和手动点上一句发言的edit没有区别。

通过一些简单的状态patch应该可以暂时屏蔽这个错误。

可能之前的会话数据服务器全部down了？
还有我这里平板用Gboard容易误触Logout #5 可以加一个New chat一样的提示

[CyanChanges]

我认为我们需要构建一些简单测试。 用于了解遭遇high demand时，ChatGPT的官方会话管理还有哪些接口可以正常工作。
毕竟：如果问题在于high demand 时 API被阻断，那么本地的会话ID管理可能不会有太大的作用。
如果对话相关的接口还能正常工作，那我们应该可以通过第三方会话管理暂时规避这个问题。 在下一次high demand状态的时候，我会尝试构建一些简单的验证确定问题。感谢反馈。

现在就high demand. @bigemon

关于本地会话管理：

一个不幸的消息是，尝试附加多个旧的会话ID时，服务器都抛出了404。 这可能意味着，high demand状态时，backend-api/conversation 接口的id检索范围从后端进行了硬性限制。而不是因为高负载导致无法加载。

关于Regenerate Response 按钮失效：

另外，Regenerate Response 按钮失效一般出现在什么情况? 在我构建的测试中暂时没发现。

已复现。 这看起来似乎是一个官方前端的错误，只会在high demand状态弹出黄色警告信息时发生。 通过上一句对话的edit功能，可以正常的重新生成。而Regenerate Response功能实际上只是一个快捷按钮，和手动点上一句发言的edit没有区别。

通过一些简单的状态patch应该可以暂时屏蔽这个错误。

实际上Regenerate Response相比Edit - Confirm Changes还是有区别的，当你在对话中停留时间过久导致Cloudflare验证token失效时，你再新建一个页面通过cf的验证，在旧的页面大概率使用Regenerate Response就会提示你Try reload this conversation. 使用Edit - Confirm Changes 则可以正常回复。

猜测是Regenerate Response没有重新生成新的message id，旧的id失效导致的错误，而Edit - Confirm Changes由于消息内容会改动所以重新生成了新的message id所以可以正常继续。

综上，Regenerate Response 和 Edit - Confirm Changes是有一些区别的。