TwitchDropsMiner 分片 Websocket 连接池深度解读199 频道上限的算术来源、连接退避重连与订阅零丢失回收【免费下载链接】TwitchDropsMinerAn app that allows you to AFK mine timed Twitch drops, with automatic drop claiming and channel switching.项目地址: https://gitcode.com/GitHub_Trending/tw/TwitchDropsMiner本文围绕 TwitchDropsMiner 的分片 Websocket 连接池websocket.py中的WebsocketPool与Websocket做逐行级的机制解读追踪 199 频道上限从 4 个常数到 1 行拒绝异常的路径拆解 3 分钟封顶的退避重连、10 秒 PONG 超时判定以及连接回收时订阅如何零丢失迁移并给出每个故障模式的源码锚点与观测入口。 从达到最大主题限制说起一次容量拒绝的故障现场用户让应用追踪某游戏下的全部直播一次新的 drops 活动上线后应用自动重排频道列表、为新游戏拉取直播并逐个订阅。随后界面停在gathering channels不再前进日志里只有一行MinerException: Maximum topics limit has been reached没有任何断线或超时记录。这不是网络问题而是这本容量账本的硬边界。所谓容量账本指的是websocket.py里由常数推导出来的订阅配额8 条连接 × 每条 50 个 topic 400 个槽位其中 2 个预留给账户级事件剩下 396 个按每频道 2 个 topic 计恰好支撑 199 个频道。README.md 声称的tracking up to 199 channels不是经验值而是 constants.py L119–L123 里一行算术的直接产物MAX_WEBSOCKETS 8 WS_TOPICS_LIMIT 50 TOPICS_PER_CHANNEL 2 MAX_TOPICS (MAX_WEBSOCKETS * WS_TOPICS_LIMIT) - BASE_TOPICS MAX_CHANNELS MAX_TOPICS // TOPICS_PER_CHANNEL改这四个常数中的任何一个上限随之变化而websocket.py的逻辑一行都不用动。三条设计原则topic 是真相、连接可丢弃、容量是算术topic 即真相连接只是运输。订阅状态的唯一事实来源是连接池里的 topic 注册表而不是一条具体的连接。单条连接死亡后它上面已发出的订阅清单被清空、标记为待重发重连后从注册表重新订阅——所以停掉一条连接回收它是安全操作不需要任何补偿逻辑。容量全部来自参数派生。分片数、单连接上限、每频道 topic 数、账户级预留位四个常数决定 199 这个上限。它们之间的比例关系为何预留 2 个槽位、为何每频道占 2 个在 constants.py 的 L117–L123 有注释可查。参数一变算术结果自动跟着变不存在需要单独维护的配置项。瞬时故障走退避不硬失败。连接层用指数退避重连、上限 3 分钟GQL 层用 60 秒封顶的退避个别服务端错误附带一次单点重试。只有真正不可恢复的故障才向上抛出。这让长驻后台应用能在断网、服务端抖动中存活而不进入崩溃-重启循环。 解剖一条缺口remove_topics的回收循环如何做到订阅零丢失取一条最典型的缺口走完整生命周期。频道的 topic 从频道上线开始stream-up事件触发 GQL 拉取流信息并生成Stream对象频道进入追踪列表时_run主循环为它注册两个WebsocketTopic——频道在线状态与直播设置变更两个推送通道twitch.py L796–L808。用户换游戏或列表缩减时主循环进入CHANNELS_CLEANUP把被移除频道的两个 topic 字符串交给连接池# twitch.py L708-L727节选 to_remove_topics [ WebsocketTopic.as_str(Channel, StreamState, channel.id), WebsocketTopic.as_str(Channel, StreamUpdate, channel.id), ] self.websocket.remove_topics(to_remove_topics)池内部的回收循环websocket.py L394–L404决定了哪些连接被停、哪些 topic 被搬走while True: count sum(len(ws.topics) for ws in self.websockets) if count (len(self.websockets) - 1) * WS_TOPICS_LIMIT: ws self.websockets.pop() recycled_topics.extend(ws.topics.values()) ws.stop_nowait(removeTrue) else: break if recycled_topics: self.add_topics(recycled_topics)语义一句话当剩余 topic 总数能被少一条连接装下时停掉最后一条连接把它的全部 topic 回收后重新摊派。被停连接stop(removeTrue)只清自己的槽位不碰池的注册表。两层去重保证不重复订阅池级add_topics先扣除已被其他连接持有的 topicwebsocket.py L363Websocket.add_topics只在新 topic 真正入库后才置变更位L305–L312。关闭这条缺口让回收正确收敛需要一次性完成三件事频道从channels表删除、其 2 个 topic 同步发出 UNLISTEN、被停连接的全部 topic 重新分配。三步任何一步缺失都留下残留——频道删了 topic 没删池继续收它的推送process_stream_state对着已不存在的频道 ID 打 error 日志twitch.py L1055–L1057连接停了 topic 没回收该频道的订阅静默丢失频道没从内存表移除错误日志会一直刷。现象清理后的频道仍持续产生推送流量或某频道在连接回收后不再有任何状态更新涉及测试CHANNELS_CLEANUP分支与WebsocketPool.remove_topics回收循环影响面全平台、全执行模式游戏切换、优先级列表变化、整点维护触发期望被停连接的全部 topic 重新出现在存活连接上被清理频道零残留观测recycled_topics只在该连接被实际停掉时收集若循环条件误判残留订阅会长期存在门控无环境开关由 topic 总数与WS_TOPICS_LIMIT的算术判定复现python main.py -vvvv --log在设置页切换 Priority 列表观察Removing topics:/Adding topics:日志行源码锚点websocket.py, L385–L404twitch.py, L694–L727 常数 → 运行时布尔 → 调用点行为一张表读完所有门控这套系统没有环境开关门控全部来自 constants.py 的 L117–L130 参数经运行时状态connected、reconnect_requested、topics_changed翻译成调用点行为配置参数运行时布尔量调用点行为源码锚点MAX_WEBSOCKETS 8循环走完 8 条连接仍有剩余 topic拒绝分配抛Maximum topics limit异常websocket.py, L357–L383WS_TOPICS_LIMIT 50len(self.topics) 50每条连接最多 50 个订阅超出的顺延到下一条连接websocket.py, L305–L312BASE_TOPICS 2预留槽位被账户事件占用user-drop-events与onsite-notifications先于频道 topic 入库twitch.py, L625–L630PING_INTERVAL 3min/PING_TIMEOUT 10snow _max_pong发PING后 10 秒内无PONG即判定连接死亡、请求重连websocket.py, L190–L199LISTEN/UNLISTEN 分块chunk(…, 20)存在新增 / 已移除 topic每次重订阅按 20 个一批发送websocket.py, L201–L240ONLINE_DELAY 120spending_online为真stream-up事件延迟 2 分钟才二次确认频道在线channel.py, L386–L410WATCH_INTERVAL 59sminute_almost_done()一轮 watch 后约 20 秒检查进度超时则触发 GQL 查询兜底twitch.py, L894–L958三层翻译路径清晰参数层constants.py→ 运行时布尔量每条连接的connected/_reconnect_requested/_topics_changed→ 调用点行为重连、重订阅、拒绝分配。排障时先定位卡在哪一层再看对应锚点。⚠️ 按症状重排五类故障模式全景症状类型共性一句话条目数容量与拒绝订阅总数越过算术上限时池整体拒绝不部分成功1连接稳定性退避重连窗口内该连接的所有推送静默丢失2订阅漂移topic 在连接间迁移时可能残留或丢失1时序竞态事件到达早于数据就绪靠延迟二次确认兜底1进度静默Twitch 侧推送停摆时靠 GQL 查询与本地累加续命2订阅第 200 个频道时池拒绝分配用户让应用追踪一个游戏的直播频道数越过 199 后新频道无法进入追踪列表主循环停在CHANNELS_FETCH状态反复报错。现象界面停在gathering channels日志出现MinerException: Maximum topics limit has been reached涉及测试WebsocketPool.add_topics的分配循环影响面全平台、全执行模式受MAX_WEBSOCKETS × WS_TOPICS_LIMIT − BASE_TOPICS约束期望预期行为——199 个频道满负荷时第 200 个频道被ordered_channels[MAX_CHANNELS:]裁剪而不是走到异常观测当 topic 总数超过8 × 50 400时抛异常_run捕获后回到IDLE状态该频道永远进不了列表门控无开关由MAX_CHANNELS199与 topic 计数共同决定复现python main.py -vvvv --log在本地副本中临时调低MAX_WEBSOCKETS至 2 后重载观察分配拒绝源码锚点websocket.py, L357–L383连接断线后经历 3 分钟封顶的指数退避重连网络抖动后应用失去某条 pubsub 连接该连接上的频道推送中断重连间隔逐步拉长但不超过 3 分钟。现象GUI 上某条连接状态从connected变为reconnecting日志出现connection problem (sleep: Xs)涉及测试Websocket._backoff_connect与_handle重连循环影响面全平台、全执行模式每次连接中断均触发期望预期行为——退避在 3 分钟封顶重连成功后该连接的全部 topic 自动重新 LISTEN观测断线时finally分支清空_submitted并置_topics_changed重连后_handle_topics自动重发全部订阅门控无开关_backoff_connect的maximum3*60参数固定复现python main.py -vvvv --log --debug-ws运行中手动断开网络 5 秒后恢复观察重连日志序列源码锚点websocket.py, L114–L142websocket.py, L153–L188PONG 超时 10 秒判定连接死亡并主动回收连接假死能发不能收时_handle_ping在 10 秒窗口内未收到PONG即主动请求重连不必等 TCP 层超时。现象日志出现didnt receive a PONG, reconnecting...涉及测试Websocket._handle_ping与_handle_recv的 PONG 处理影响面全平台每次 PING 周期3 分钟触发一次判定期望预期行为——10 秒内无 PONG 即判定死亡重连后 topic 自动恢复观测_max_pong在 PING 发出时设为now 10s收到 PONG 时重置为_next_ping远未来避免误判门控PING_INTERVAL3min与PING_TIMEOUT10s两个常数复现python main.py -vvvv --debug-ws用代理工具拦截 PONG 响应 15 秒观察重连触发源码锚点websocket.py, L190–L199websocket.py, L292–L294频道下线后其 2 个 topic 残留于某条连接频道被清理离线或换游戏后对应 topic 未随CHANNELS_CLEANUP同步 UNLISTEN池继续接收该频道推送。现象日志出现Stream state change for a non-existing channel: id的 error 行涉及测试CHANNELS_CLEANUP分支与process_stream_state影响面全平台每次清理循环均可能触发期望预期行为——频道从channels表删除的同时其 2 个 topic 发出 UNLISTEN观测若remove_topics未被调用或 topic 字符串拼写不一致残留订阅长期存在推送持续到达门控无开关由CHANNELS_CLEANUP分支的to_remove_topics列表内容决定复现python main.py -vvvv --log观察清理阶段的Removing topics:行是否与 GUI 中消失的频道一一对应源码锚点twitch.py, L694–L727twitch.py, L1052–L1075stream-up事件早于 GQL 数据到达时的 120 秒二次确认stream-uppubsub 事件在频道真正可查之前就已到达应用不能立即标记 ONLINE否则 GQL 查不到流信息会误判为 OFFLINE。现象频道在 GUI 中显示为即将上线状态约 2 分钟后才变为 ONLINE涉及测试Channel.check_online与_online_delay影响面全平台每次stream-up事件触发期望预期行为——延迟 120 秒后调update_stream()二次确认避免竞态误判观测_pending_stream_up任务在 120 秒内可被set_offline取消防止已下线频道被错误标记门控ONLINE_DELAY 120s常数复现python main.py -vvvv --log观察goes ONLINE日志与stream-up事件之间的时间差源码锚点channel.py, L386–L410twitch.py, L1067–L1070进度推送静默 60 秒以上时倒计时卡在最后一分钟Twitch 侧drop-progress推送间隔可能超过 60 秒倒计时停在最后一分钟不再推进。现象GUI 倒计时静止日志无drop-progress行涉及测试_watch_loop的进度检查与 GQL 兜底影响面全平台每次推送间隔超过 60 秒触发期望预期行为——触发CurrentDropGQL 查询恢复进度GQL 失败则本地累加分钟数观测gql_request的CurrentDrop查询在_watch_loop内被调用失败后走bump_minutes兜底门控WATCH_INTERVAL59s与minute_almost_done()布尔量复现python main.py -vvvv --log观察Drop progress from GQL:或Drop progress from active search:日志行源码锚点twitch.py, L908–L954GQL 服务端错误时错误路径字段被置空而非整批失败GQL 响应中携带server error时应用不抛异常而是沿错误路径把对应字段置为None让上层逻辑优雅降级。现象某次Inventory查询返回中部分 campaign 字段为null应用不崩溃涉及测试gql_request的错误处理分支影响面全平台每次 GQL 响应含server error时触发期望预期行为——错误路径上的字段被置空其余字段正常返回观测data_dict[path[-1]] None执行后_merge_data遇到None值会跳过该 campaign门控无开关由 GQL 响应体中的errors数组内容决定复现python main.py -vvvv --debug-gql观察GQL Response:行中是否含server error源码锚点twitch.py, L1344–L1351复现速查条目观测方式入口文件关键标识容量拒绝-vvvv --logtwitch.pyMaximum topics limit has been reached断线重连-vvvv --debug-wswebsocket.pyreconnecting.../connected.PONG 超时--debug-wswebsocket.pydidnt receive a PONG订阅残留-vvvv --logtwitch.pyStream state change for a non-existing channel上线延迟-vvvv --logchannel.pygoes ONLINE与stream-up时间差进度静默-vvvv --logtwitch.pyDrop progress from GQL:/from active search:GQL 降级-vvvv --debug-gqltwitch.pyGQL Response:中含server error可迁移经验对任何长驻后台订阅系统状态外置于连接——把订阅注册表与连接生命周期解耦——是断线重连零丢失的地基连接死了状态还在重连就是重放注册表。容量上限用常数算术而非经验值让为什么是 199变成一行可验证的公式改参数即改行为不存在配置漂移。退避封顶加单点重试的组合比无限退避或立即失败都更适合 24 小时后台进程前者让瞬时故障自愈后者避免在不可恢复故障上空转。【免费下载链接】TwitchDropsMinerAn app that allows you to AFK mine timed Twitch drops, with automatic drop claiming and channel switching.项目地址: https://gitcode.com/GitHub_Trending/tw/TwitchDropsMiner创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/20 1:52:21 · 阅读 1.2k TwitchDropsMiner 分片 Websocket 连接池深度解读：199 频道上限的算术来源、连接退避重连与订阅零丢失回收
TwitchDropsMiner 分片 Websocket 连接池深度解读199 频道上限的算术来源、连接退避重连与订阅零丢失回收【免费下载链接】TwitchDropsMinerAn app that allows you to AFK mine timed Twitch drops, with automatic drop claiming and channel switching.项目地址: https://gitcode.com/GitHub_Trending/tw/TwitchDropsMiner本文围绕 TwitchDropsMiner 的分片 Websocket 连接池websocket.py中的WebsocketPool与Websocket做逐行级的机制解读追踪 199 频道上限从 4 个常数到 1 行拒绝异常的路径拆解 3 分钟封顶的退避重连、10 秒 PONG 超时判定以及连接回收时订阅如何零丢失迁移并给出每个故障模式的源码锚点与观测入口。 从达到最大主题限制说起一次容量拒绝的故障现场用户让应用追踪某游戏下的全部直播一次新的 drops 活动上线后应用自动重排频道列表、为新游戏拉取直播并逐个订阅。随后界面停在gathering channels不再前进日志里只有一行MinerException: Maximum topics limit has been reached没有任何断线或超时记录。这不是网络问题而是这本容量账本的硬边界。所谓容量账本指的是websocket.py里由常数推导出来的订阅配额8 条连接 × 每条 50 个 topic 400 个槽位其中 2 个预留给账户级事件剩下 396 个按每频道 2 个 topic 计恰好支撑 199 个频道。README.md 声称的tracking up to 199 channels不是经验值而是 constants.py L119–L123 里一行算术的直接产物MAX_WEBSOCKETS 8 WS_TOPICS_LIMIT 50 TOPICS_PER_CHANNEL 2 MAX_TOPICS (MAX_WEBSOCKETS * WS_TOPICS_LIMIT) - BASE_TOPICS MAX_CHANNELS MAX_TOPICS // TOPICS_PER_CHANNEL改这四个常数中的任何一个上限随之变化而websocket.py的逻辑一行都不用动。三条设计原则topic 是真相、连接可丢弃、容量是算术topic 即真相连接只是运输。订阅状态的唯一事实来源是连接池里的 topic 注册表而不是一条具体的连接。单条连接死亡后它上面已发出的订阅清单被清空、标记为待重发重连后从注册表重新订阅——所以停掉一条连接回收它是安全操作不需要任何补偿逻辑。容量全部来自参数派生。分片数、单连接上限、每频道 topic 数、账户级预留位四个常数决定 199 这个上限。它们之间的比例关系为何预留 2 个槽位、为何每频道占 2 个在 constants.py 的 L117–L123 有注释可查。参数一变算术结果自动跟着变不存在需要单独维护的配置项。瞬时故障走退避不硬失败。连接层用指数退避重连、上限 3 分钟GQL 层用 60 秒封顶的退避个别服务端错误附带一次单点重试。只有真正不可恢复的故障才向上抛出。这让长驻后台应用能在断网、服务端抖动中存活而不进入崩溃-重启循环。 解剖一条缺口remove_topics的回收循环如何做到订阅零丢失取一条最典型的缺口走完整生命周期。频道的 topic 从频道上线开始stream-up事件触发 GQL 拉取流信息并生成Stream对象频道进入追踪列表时_run主循环为它注册两个WebsocketTopic——频道在线状态与直播设置变更两个推送通道twitch.py L796–L808。用户换游戏或列表缩减时主循环进入CHANNELS_CLEANUP把被移除频道的两个 topic 字符串交给连接池# twitch.py L708-L727节选 to_remove_topics [ WebsocketTopic.as_str(Channel, StreamState, channel.id), WebsocketTopic.as_str(Channel, StreamUpdate, channel.id), ] self.websocket.remove_topics(to_remove_topics)池内部的回收循环websocket.py L394–L404决定了哪些连接被停、哪些 topic 被搬走while True: count sum(len(ws.topics) for ws in self.websockets) if count (len(self.websockets) - 1) * WS_TOPICS_LIMIT: ws self.websockets.pop() recycled_topics.extend(ws.topics.values()) ws.stop_nowait(removeTrue) else: break if recycled_topics: self.add_topics(recycled_topics)语义一句话当剩余 topic 总数能被少一条连接装下时停掉最后一条连接把它的全部 topic 回收后重新摊派。被停连接stop(removeTrue)只清自己的槽位不碰池的注册表。两层去重保证不重复订阅池级add_topics先扣除已被其他连接持有的 topicwebsocket.py L363Websocket.add_topics只在新 topic 真正入库后才置变更位L305–L312。关闭这条缺口让回收正确收敛需要一次性完成三件事频道从channels表删除、其 2 个 topic 同步发出 UNLISTEN、被停连接的全部 topic 重新分配。三步任何一步缺失都留下残留——频道删了 topic 没删池继续收它的推送process_stream_state对着已不存在的频道 ID 打 error 日志twitch.py L1055–L1057连接停了 topic 没回收该频道的订阅静默丢失频道没从内存表移除错误日志会一直刷。现象清理后的频道仍持续产生推送流量或某频道在连接回收后不再有任何状态更新涉及测试CHANNELS_CLEANUP分支与WebsocketPool.remove_topics回收循环影响面全平台、全执行模式游戏切换、优先级列表变化、整点维护触发期望被停连接的全部 topic 重新出现在存活连接上被清理频道零残留观测recycled_topics只在该连接被实际停掉时收集若循环条件误判残留订阅会长期存在门控无环境开关由 topic 总数与WS_TOPICS_LIMIT的算术判定复现python main.py -vvvv --log在设置页切换 Priority 列表观察Removing topics:/Adding topics:日志行源码锚点websocket.py, L385–L404twitch.py, L694–L727 常数 → 运行时布尔 → 调用点行为一张表读完所有门控这套系统没有环境开关门控全部来自 constants.py 的 L117–L130 参数经运行时状态connected、reconnect_requested、topics_changed翻译成调用点行为配置参数运行时布尔量调用点行为源码锚点MAX_WEBSOCKETS 8循环走完 8 条连接仍有剩余 topic拒绝分配抛Maximum topics limit异常websocket.py, L357–L383WS_TOPICS_LIMIT 50len(self.topics) 50每条连接最多 50 个订阅超出的顺延到下一条连接websocket.py, L305–L312BASE_TOPICS 2预留槽位被账户事件占用user-drop-events与onsite-notifications先于频道 topic 入库twitch.py, L625–L630PING_INTERVAL 3min/PING_TIMEOUT 10snow _max_pong发PING后 10 秒内无PONG即判定连接死亡、请求重连websocket.py, L190–L199LISTEN/UNLISTEN 分块chunk(…, 20)存在新增 / 已移除 topic每次重订阅按 20 个一批发送websocket.py, L201–L240ONLINE_DELAY 120spending_online为真stream-up事件延迟 2 分钟才二次确认频道在线channel.py, L386–L410WATCH_INTERVAL 59sminute_almost_done()一轮 watch 后约 20 秒检查进度超时则触发 GQL 查询兜底twitch.py, L894–L958三层翻译路径清晰参数层constants.py→ 运行时布尔量每条连接的connected/_reconnect_requested/_topics_changed→ 调用点行为重连、重订阅、拒绝分配。排障时先定位卡在哪一层再看对应锚点。⚠️ 按症状重排五类故障模式全景症状类型共性一句话条目数容量与拒绝订阅总数越过算术上限时池整体拒绝不部分成功1连接稳定性退避重连窗口内该连接的所有推送静默丢失2订阅漂移topic 在连接间迁移时可能残留或丢失1时序竞态事件到达早于数据就绪靠延迟二次确认兜底1进度静默Twitch 侧推送停摆时靠 GQL 查询与本地累加续命2订阅第 200 个频道时池拒绝分配用户让应用追踪一个游戏的直播频道数越过 199 后新频道无法进入追踪列表主循环停在CHANNELS_FETCH状态反复报错。现象界面停在gathering channels日志出现MinerException: Maximum topics limit has been reached涉及测试WebsocketPool.add_topics的分配循环影响面全平台、全执行模式受MAX_WEBSOCKETS × WS_TOPICS_LIMIT − BASE_TOPICS约束期望预期行为——199 个频道满负荷时第 200 个频道被ordered_channels[MAX_CHANNELS:]裁剪而不是走到异常观测当 topic 总数超过8 × 50 400时抛异常_run捕获后回到IDLE状态该频道永远进不了列表门控无开关由MAX_CHANNELS199与 topic 计数共同决定复现python main.py -vvvv --log在本地副本中临时调低MAX_WEBSOCKETS至 2 后重载观察分配拒绝源码锚点websocket.py, L357–L383连接断线后经历 3 分钟封顶的指数退避重连网络抖动后应用失去某条 pubsub 连接该连接上的频道推送中断重连间隔逐步拉长但不超过 3 分钟。现象GUI 上某条连接状态从connected变为reconnecting日志出现connection problem (sleep: Xs)涉及测试Websocket._backoff_connect与_handle重连循环影响面全平台、全执行模式每次连接中断均触发期望预期行为——退避在 3 分钟封顶重连成功后该连接的全部 topic 自动重新 LISTEN观测断线时finally分支清空_submitted并置_topics_changed重连后_handle_topics自动重发全部订阅门控无开关_backoff_connect的maximum3*60参数固定复现python main.py -vvvv --log --debug-ws运行中手动断开网络 5 秒后恢复观察重连日志序列源码锚点websocket.py, L114–L142websocket.py, L153–L188PONG 超时 10 秒判定连接死亡并主动回收连接假死能发不能收时_handle_ping在 10 秒窗口内未收到PONG即主动请求重连不必等 TCP 层超时。现象日志出现didnt receive a PONG, reconnecting...涉及测试Websocket._handle_ping与_handle_recv的 PONG 处理影响面全平台每次 PING 周期3 分钟触发一次判定期望预期行为——10 秒内无 PONG 即判定死亡重连后 topic 自动恢复观测_max_pong在 PING 发出时设为now 10s收到 PONG 时重置为_next_ping远未来避免误判门控PING_INTERVAL3min与PING_TIMEOUT10s两个常数复现python main.py -vvvv --debug-ws用代理工具拦截 PONG 响应 15 秒观察重连触发源码锚点websocket.py, L190–L199websocket.py, L292–L294频道下线后其 2 个 topic 残留于某条连接频道被清理离线或换游戏后对应 topic 未随CHANNELS_CLEANUP同步 UNLISTEN池继续接收该频道推送。现象日志出现Stream state change for a non-existing channel: id的 error 行涉及测试CHANNELS_CLEANUP分支与process_stream_state影响面全平台每次清理循环均可能触发期望预期行为——频道从channels表删除的同时其 2 个 topic 发出 UNLISTEN观测若remove_topics未被调用或 topic 字符串拼写不一致残留订阅长期存在推送持续到达门控无开关由CHANNELS_CLEANUP分支的to_remove_topics列表内容决定复现python main.py -vvvv --log观察清理阶段的Removing topics:行是否与 GUI 中消失的频道一一对应源码锚点twitch.py, L694–L727twitch.py, L1052–L1075stream-up事件早于 GQL 数据到达时的 120 秒二次确认stream-uppubsub 事件在频道真正可查之前就已到达应用不能立即标记 ONLINE否则 GQL 查不到流信息会误判为 OFFLINE。现象频道在 GUI 中显示为即将上线状态约 2 分钟后才变为 ONLINE涉及测试Channel.check_online与_online_delay影响面全平台每次stream-up事件触发期望预期行为——延迟 120 秒后调update_stream()二次确认避免竞态误判观测_pending_stream_up任务在 120 秒内可被set_offline取消防止已下线频道被错误标记门控ONLINE_DELAY 120s常数复现python main.py -vvvv --log观察goes ONLINE日志与stream-up事件之间的时间差源码锚点channel.py, L386–L410twitch.py, L1067–L1070进度推送静默 60 秒以上时倒计时卡在最后一分钟Twitch 侧drop-progress推送间隔可能超过 60 秒倒计时停在最后一分钟不再推进。现象GUI 倒计时静止日志无drop-progress行涉及测试_watch_loop的进度检查与 GQL 兜底影响面全平台每次推送间隔超过 60 秒触发期望预期行为——触发CurrentDropGQL 查询恢复进度GQL 失败则本地累加分钟数观测gql_request的CurrentDrop查询在_watch_loop内被调用失败后走bump_minutes兜底门控WATCH_INTERVAL59s与minute_almost_done()布尔量复现python main.py -vvvv --log观察Drop progress from GQL:或Drop progress from active search:日志行源码锚点twitch.py, L908–L954GQL 服务端错误时错误路径字段被置空而非整批失败GQL 响应中携带server error时应用不抛异常而是沿错误路径把对应字段置为None让上层逻辑优雅降级。现象某次Inventory查询返回中部分 campaign 字段为null应用不崩溃涉及测试gql_request的错误处理分支影响面全平台每次 GQL 响应含server error时触发期望预期行为——错误路径上的字段被置空其余字段正常返回观测data_dict[path[-1]] None执行后_merge_data遇到None值会跳过该 campaign门控无开关由 GQL 响应体中的errors数组内容决定复现python main.py -vvvv --debug-gql观察GQL Response:行中是否含server error源码锚点twitch.py, L1344–L1351复现速查条目观测方式入口文件关键标识容量拒绝-vvvv --logtwitch.pyMaximum topics limit has been reached断线重连-vvvv --debug-wswebsocket.pyreconnecting.../connected.PONG 超时--debug-wswebsocket.pydidnt receive a PONG订阅残留-vvvv --logtwitch.pyStream state change for a non-existing channel上线延迟-vvvv --logchannel.pygoes ONLINE与stream-up时间差进度静默-vvvv --logtwitch.pyDrop progress from GQL:/from active search:GQL 降级-vvvv --debug-gqltwitch.pyGQL Response:中含server error可迁移经验对任何长驻后台订阅系统状态外置于连接——把订阅注册表与连接生命周期解耦——是断线重连零丢失的地基连接死了状态还在重连就是重放注册表。容量上限用常数算术而非经验值让为什么是 199变成一行可验证的公式改参数即改行为不存在配置漂移。退避封顶加单点重试的组合比无限退避或立即失败都更适合 24 小时后台进程前者让瞬时故障自愈后者避免在不可恢复故障上空转。【免费下载链接】TwitchDropsMinerAn app that allows you to AFK mine timed Twitch drops, with automatic drop claiming and channel switching.项目地址: https://gitcode.com/GitHub_Trending/tw/TwitchDropsMiner创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考